Re: 4.x buildworlds broken on -current
On Sat, 10 Jun 2000, Kris Kennaway wrote: Recent compiler changes seem to have broken the ability to do 4.x buildworlds under -current - I've tested this on beast.freebsd.org and my own machines and got the same result. The build dies during the compiler phase with lots of stuff like: /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `finish_function': c-decl.o(.text+0x8360): multiple definition of `finish_function' decl.o(.text+0x10880): first defined here /usr/libexec/elf/ld: Warning: size of symbol `finish_function' changed from 3003 to 565 in c-decl.o ... This is a bug in the cc Makefiles in 4.x. It was fixed in -current in: # RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_int/Makefile,v # Working file: Makefile # head: 1.26 # ... # # revision 1.26 # date: 2000/05/24 20:02:21; author: obrien; state: Exp; lines: +2 -2 # Move c-decl.c out of the common libcc_int.a into the binary Makefiles # where it is used. c-decl has symbols that conflict with several of the # cc1plus sources. # # GNU `ld' was changed in Dec 1999 to be more be compatable with the way that # other linkers work (specifically in the Solaris linker). The 2.9.1 `ld', # did the Wrong Thing in that if a library contained a common symbol that # matched a definition of that symbol in another (already linked in object) # it would also be linked in, even if there was no other reason to do so. # This is wrong. The library should only be linked in if it contains # non-common, non-weak symbols which are needed by previously linked in # objects. # etc. This could be fixed by MFC to RELENG_4, but bootstrapping from 4.0, 3.x and 2.x is much harder to fix. Building old kernels under -current is becoming difficult. I build kernels for RELENG_3 and RELENG_4. This causes a lot of new warnings about invalid assembler, but still works, at least a week ago. I left genassym(1) in /usr/bin to avoid breaking the build of RELENG_4 kernels until the genassym changes are MFC'ed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Think about it. If you mix a random number with a non-random number, using xor, what you get is a random number. It's neither stronger nor weaker. No, you'll get weaker random number, it badly affects random distribution. OR or AND will affect more. What you say is true only if second XOR part is 0 or -1 or changed between them or simple constant. I.e. if not _all_ bits XORed in the same way, it affects. Andrey, this is simply not true. A fundamental theorem of randomness is that random bits XORed onto your data is random. How do you think a one-time-pad works? I suggest you read Bruce Schneier's Cryptography book before continuing this debate. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
If it not weakers I can't see why it strenghthens. I.e. you can constantly strenghthens generator with passing it through XOR -1 ? If not, why any other value is better than -1? Huh? -1 is a constant, not random. Pass your data through _random_ bits, XORing it with them, and you have unbreakable crypto (one-time-pad) if you make a record of the random bits (the key). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
BTW, if they have the same bits number, there is no reason to XOR random with predictable, random is not become more random. But still confirm this. If the random number is truly random, then you are correct. If there are attacks on your random number generator, then XORing other stuff onto it will perturb the result and help defences. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sun, Jun 11, 2000 at 09:24:37AM +0200, Mark Murray wrote: If it not weakers I can't see why it strenghthens. I.e. you can constantly strenghthens generator with passing it through XOR -1 ? If not, why any other value is better than -1? Huh? -1 is a constant, not random. Pass your data through _random_ bits, XORing it with them, and you have unbreakable crypto (one-time-pad) if you make a record of the random bits (the key). Yes, if passing _random_ through -1 _data_ not makes it strengthens, passing through 1,2,3,4... _data_ will not makes it strenghthens too. If attacker tries to predict random number generator itself and know pid and mktemp() algorithm, adding getpid() bits he already know will not stop him from this attack unless you plan to keep mktemp() algorihtm secret. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Huh? -1 is a constant, not random. Pass your data through _random_ bits, XORing it with them, and you have unbreakable crypto (one-time-pad) if you make a record of the random bits (the key). Yes, if passing _random_ through -1 _data_ not makes it strengthens, passing through 1,2,3,4... _data_ will not makes it strenghthens too. Right, but the attacker doesn't always have access to the pid, so while it is _not_very_ random, under some circumstances it has _some_ useful randomness. If attacker tries to predict random number generator itself and know pid and mktemp() algorithm, adding getpid() bits he already know will not stop him from this attack unless you plan to keep mktemp() algorihtm secret. Correct. However if you are collecting bits of randomness (or suspected randomness) from various sources, XORing them together is a cheap way of of combining them and obfuscating them, without making the total randomness any worse than the best of them. There are ways (eg: hash algorithms) of adding the total randomness. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: The diff should make a process at -20 which uses all available CPU schedule just slightly the ahead of a process at +20 which uses no CPU. A process which uses full CPU at 0 niceness would have a priority of 128, whereas a process using no CPU at 0 niceness would have a priority of 90. All processes will always have a priority less than or equal to 128, which is the priority at which a process with a niceness of +20 always runs at. A +20 process won't get better priority than anything else, period. Try it out, see how it works for you:) I tried this patch today. While it didn't quite fix the problem, it sure made for some interesting pacman gameplay. ;-) Using idprio as Volodymyr suggested seems to be a viable workaround. You mentioned in another message that idprio could potentially deadlock my machine, though. Under what conditions could this happen (and how likely is it to occur)? -jake -- Jacob A. Hart [EMAIL PROTECTED] Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 PGP signature
Re: Scheduler changes?
Using idprio as Volodymyr suggested seems to be a viable workaround. You mentioned in another message that idprio could potentially deadlock my machine, though. Under what conditions could this happen (and how likely is it to occur)? idprio can lead to a system hang due to priority inversion. For example, suppose that an idprio process does disk I/O and locks a critical resource (such as the vnode for the '/' directory) prior to doing that. Then also suppose that a normal process is in a permanent run state (loop: goto loop). When the I/O completes on the idprio process, it will never be given an opportunity to release the vnode lock. Eventually just about everything in the system will deadlock waiting on that resource and the system will essentially hang. The work-around for this is to temporarily increase the priority of idprio processes while they execute in the kernel, but this hasn't yet been implemented. The above scenario can happen pretty easily if you have an idprio process doing a normal mix of file operations - all you need then is normal priority process(es) to eat all the CPU for long periods - even a few seconds can be very annoying to interactive users. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Newmidi Release Candidate is ready
The release candidate of newmidi is finally ready. The patch for -current can be found at: URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz I will put this patch into the final test stage of 1 month. The date of merge is hence going to be 11th July 2000. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
word processor
unable to open word processor. pop-up says error has occurred and shuts down. have run system. clean up,scandisk,defrag,etc. but program still will not open. please help if possible To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Sun, 11 Jun 2000, Jacob A. Hart wrote: On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: The diff should make a process at -20 which uses all available CPU schedule just slightly the ahead of a process at +20 which uses no CPU. A process which uses full CPU at 0 niceness would have a priority of 128, whereas a process using no CPU at 0 niceness would have a priority of 90. All processes will always have a priority less than or equal to 128, which is the priority at which a process with a niceness of +20 always runs at. A +20 process won't get better priority than anything else, period. Try it out, see how it works for you:) I tried this patch today. While it didn't quite fix the problem, it sure made for some interesting pacman gameplay. ;-) Yeah, I tried it out myself. I didn't actually think beforehand (hence the testing...) why it would be bad for a process of niceness -20 to always have better than the last priority in every case... I tried it with MAME and it took a long time before my "escape" key event registered (X not getting run...). I'm thinking of ways to make the algorithm both good for people who need (err... want) low-priority background processes only to run when there's free time, and high-priority processes run but not to the exclusion of everything else. The whole scheduling algorithm proper is quite tricky to do very well; previously, it had most of the properties we want, but it also easily allowed for deadlocks. Using idprio as Volodymyr suggested seems to be a viable workaround. You mentioned in another message that idprio could potentially deadlock my machine, though. Under what conditions could this happen (and how likely is it to occur)? -jake -- Jacob A. Hart [EMAIL PROTECTED] Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel config errors...
After a recent cvsup, I'm getting this error after doing a config -r: ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
Hi, i understand that this means maybe a somwthat large change in the system, but what do you think if we have a lok at implementing the CPU scheduler using weights instead of strict priorities ? Do we have parts of the kernel which rely on priority to implement locking etc ? This would not be too different from what the EclipseBSD people did, and the code i recently committed to dummynet can be easily reused to this purpose, and it is efficient. With a little bit of guidance (I am not too familiar with that area of the code) i think we can do something good with little effort. cheers luigi On Sun, 11 Jun 2000, Jacob A. Hart wrote: On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: The diff should make a process at -20 which uses all available CPU schedule just slightly the ahead of a process at +20 which uses no CPU. A process which uses full CPU at 0 niceness would have a priority of 128, whereas a process using no CPU at 0 niceness would have a priority of 90. All processes will always have a priority less than or equal to 128, which is the priority at which a process with a niceness of +20 always runs at. A +20 process won't get better priority than anything else, period. Try it out, see how it works for you:) I tried this patch today. While it didn't quite fix the problem, it sure made for some interesting pacman gameplay. ;-) Yeah, I tried it out myself. I didn't actually think beforehand (hence the testing...) why it would be bad for a process of niceness -20 to always have better than the last priority in every case... I tried it with MAME and it took a long time before my "escape" key event registered (X not getting run...). I'm thinking of ways to make the algorithm both good for people who need (err... want) low-priority background processes only to run when there's free time, and high-priority processes run but not to the exclusion of everything else. The whole scheduling algorithm proper is quite tricky to do very well; previously, it had most of the properties we want, but it also easily allowed for deadlocks. Using idprio as Volodymyr suggested seems to be a viable workaround. You mentioned in another message that idprio could potentially deadlock my machine, though. Under what conditions could this happen (and how likely is it to occur)? -jake -- Jacob A. Hart [EMAIL PROTECTED] Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel config errors...
In message [EMAIL PROTECTED], Donn Mi ller writes: After a recent cvsup, I'm getting this error after doing a config -r: ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard recompile config(8). I don't know why peter didn't bump the magic-config-version-number. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. While I have reservations about the latter, I'm not objecting to it. If you, Luoqi, prefer to go that way, go ahead. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Upgrading from 4.0-RELEASE broken
I always get bitten by these bugs while trying to upgrade a 4.0-RELEASE
box to 5.0-CURRENT via make world:
Problem #1:
=== libcrypto
perl
/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/objects/obj_dat.
pl
/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/objects/objects.
h /usr/obj/usr/src/secure/lib/libcrypto/obj_dat.h
Can't open input file at
/usr/src/secure/lib/libcrypto/../../../crypto/openssl/cr
ypto/objects/obj_dat.pl line 41.
*** Error code 2
Stop in /usr/src/secure/lib/libcrypto.
*** Error code 1
Fix #1:
+++ obj_dat.pl.bak Sun Jun 11 16:56:31 2000
--- obj_dat.pl Sun Jun 11 16:56:52 2000
@@ -38,8 +38,8 @@
return(%objn);
}
-open (IN,"$ARGV[0]") || die "Can't open input file $ARGV[0]";
-open (OUT,"$ARGV[1]") || die "Can't open output file $ARGV[1]";
+#open (IN,"$ARGV[0]") || die "Can't open input file $ARGV[0]";
+#open (OUT,"$ARGV[1]") || die "Can't open output file $ARGV[1]";
while (IN)
{
Problem #2:
cc -O -pipe -Wall -DHAVE_DES -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr
.sbin/ppp/ether.c
cc -O -pipe -Wall -DHAVE_DES -I/usr/obj/usr/src/i386/usr/include -o
ppp acf.o a
rp.o async.o auth.o bundle.o cbcp.o ccp.o chap.o chat.o command.o
datalink.o defla
te.o defs.o exec.o filter.o fsm.o hdlc.o id.o iface.o ip.o ipcp.o
iplist.o lcp.o l
ink.o log.o lqr.o main.o mbuf.o mp.o pap.o physical.o pred.o probe.o
prompt.o prot
o.o route.o server.o sig.o slcompress.o sync.o systems.o tcp.o
throughput.o timer.
o tty.o tun.o udp.o vjcomp.o nat_cmd.o chap_ms.o radius.o i4b.o ether.o
-lcrypt -
lmd -lutil -lz -lalias -lcrypto -lradius -lnetgraph
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_get_att
r_by_OBJ'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_CERT_AUX_
free'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`OpenSSL_add_al
l_ciphers'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`d2i_X509_CERT_
AUX'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`BN_CTX_new'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_add1_at
tr_by_txt'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`BN_CTX_get'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_CERT_AUX_
print'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`BN_CTX_end'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_add1_at
tr_by_NID'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`BN_CTX_start'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`BN_CTX_init'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_PURPOSE_g
et0'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`OpenSSL_add_al
l_digests'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`i2d_X509_CERT_
AUX'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_get_att
r'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_get_att
r_count'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`v3_info'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_TRUST_get
_by_id'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_PURPOSE_g
et_by_id'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_check_tru
st'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_delete_
attr'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`BN_CTX_free'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`ERR_load_RAND_
strings'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_add1_at
tr'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`ASN1_STRING_se
t_by_NID'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_get_att
r_by_NID'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509at_add1_at
tr_by_OBJ'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`X509_check_pur
pose'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`CRYPTO_mem_ctr
l'
/usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to
`DSA_OpenSSL'
*** Error code 1
Stop in /usr/src/usr.sbin/ppp.
*** Error code 1
Fix #2:
No idea how to fix this...
--
Andre
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RE: Strange rpc.statd and mount_nfs
On 11-Jun-00 Matthew Dillon wrote:
:Here is a rather suspicious fix, I have not looked at rpc call
:use in detail:
:
:--- mount_nfs.c.origSat Jun 10 11:08:19 2000
:+++ mount_nfs.c Sat Jun 10 11:09:06 2000
:@@ -784,10 +784,11 @@
:warnx("%s", clnt_sperror(clp,
:"bad MNT RPC"));
:} else {
:- auth_destroy(clp-cl_auth);
:- clnt_destroy(clp);
:retrycnt = 0;
:}
:+ auth_destroy(clp-cl_auth);
:+ clnt_destroy(clp);
:+ so = RPC_ANYSOCK;
Good catch! This patch looks good to me, I am going to go ahead
and commit it.
Resetting 'so' is good code form, but I went through the rpc code
and it wasn't an operational bug ... the rpc code can overwrite so
in the case of a failure but only with '-1', which is RPC_ANYSOCK
anyway. Still, it's good not to make assumptions.
-Matt
Without the "so = RPC_ANYSOCK" and no other changes, the "weak credential"
failure turned into a "bad file descriptor" failure, so I think the non -1
socket fd is being reused. Perhaps the initialization of "so" should be moved
into the retry loop.
Jonathan Hanna [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
static linked files in /usr/bin
Hi all! Why a lot of files in /usr/bin(sbin) are static linked? for example, tar: static - 272832 bytes(83416 dynamic) is it magic of /usr/src/gnu folder? Bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. or 3) add inw and outw Forth words, and make the VMWARE specific stuff just new words defined in Forth. Perhaps this doesn't preclude having to do 1) for some future problem, but it could delay it somewhat. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Newmidi Release Candidate is ready
Seigo Tanimura wrote: The release candidate of newmidi is finally ready. The patch for -current can be found at: URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz I tried this patch out. When I added nothing to my kernel config file other than device sbc0 device pcm0 the kernel compiled OK, but when I did cat midifile.mid /dev/midi0, I get a "device not configured" error message. I figured I needed to add something to my kernel config file, such as device midi0 # for isa pnp/pci cards pseudo-device seq 1 I get a whole bunch of kernel compile errors. Examples: In file included from ../../dev/sound/midi/midi.h:69, from ../../dev/sound/isa/emu8000.c:38: ../../dev/sound/midi/miditypes.h:65: redefinition of `mididev_info' ../../dev/sound/midi/miditypes.h:31: `mididev_info' previously declared here ../../dev/sound/midi/miditypes.h:67: redefinition of `midi_callback_t' ../../dev/sound/midi/miditypes.h:33: `midi_callback_t' previously declared here ../../dev/sound/midi/miditypes.h:68: redefinition of `midi_intr_t' ../../dev/sound/midi/miditypes.h:34: `midi_intr_t' previously declared here ../../dev/sound/midi/miditypes.h:99: redefinition of `mididev_info' ../../dev/sound/midi/miditypes.h:65: `mididev_info' previously declared here ../../dev/sound/midi/miditypes.h:101: redefinition of `midi_callback_t' ../../dev/sound/midi/miditypes.h:67: `midi_callback_t' previously declared here ../../dev/sound/midi/miditypes.h:102: redefinition of `midi_intr_t' ../../dev/sound/midi/miditypes.h:68: `midi_intr_t' previously declared here ../../dev/sound/midi/miditypes.h:133: redefinition of `mididev_info' ../../dev/sound/midi/miditypes.h:99: `mididev_info' previously declared here ../../dev/sound/midi/miditypes.h:135: redefinition of `midi_callback_t' ../../dev/sound/midi/miditypes.h:101: `midi_callback_t' previously declared here ../../dev/sound/midi/miditypes.h:136: redefinition of `midi_intr_t' ../../dev/sound/midi/miditypes.h:102: `midi_intr_t' previously declared here Also, the pcm driver for the ESS 1868 is slightly broken for MP3's -- when I try to play MP3's, I get a lot of nasty pops and clicks during playback with mpg123. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with PCM and ESS 1868
The recent commits to PCM, as of a few days back, have given me problems with my ESS 1868. When I play MP3's with mpg123, I get a lot of loud pops and clicks during playback. Otherwise, the MP3s DO play all the way through. However, when I try to play MP3s with Real Player 7, it just hangs at the beginning, and doesn't play the MP3. Before the commits to PCM, I was able to play MP3s OK with Real Player 7. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange messages at bootup
I would hazard the guess that you now have the PNPBIOS directive in your kernel config file... Actually, I don't have PnP in my config file. That's why I think this is so weird... It's on by default now. Can I turn it off somehow? Or otherwise fix it? No. The messages are harmless; you can ignore them. Go worry about global warming, or someting more important. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
"Daniel C. Sobral" wrote: Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. While I have reservations about the latter, I'm not objecting to it. If you, Luoqi, prefer to go that way, go ahead. Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, etc. This is applicable to any platform that may have some sort of emulator. Putting it in an environment variable has the advantage of having it passed through to the kernel environment too, so you might be able to use it in /etc/rc* as well. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel config errors...
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Donn Mi ller writes: After a recent cvsup, I'm getting this error after doing a config -r: ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard recompile config(8). I don't know why peter didn't bump the magic-config-version-number. I did. But it seems the magic number checking is done after other work. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Peter Wemm wrote: 2) Add the VMware detecting to FICL, as originally suggested. Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, etc. This is applicable to any platform that may have some sort of emulator. Putting it in an environment variable has the advantage of having it passed through to the kernel environment too, so you might be able to use it in /etc/rc* as well. It wouldn't change the matter of having port-specific code on loader. It is really irrelevant whether that code will be setting an environment variable or returning flag/version. Forth code executed at run-time is an extension of loader. It can call various flag-returning words and set an environment variable accordingly. The only difference is that having C code set the environment variable let us get away from using FICL, but, then, the utility of it is _only_ passing it to the kernel environment, as loader(8) without FICL can do very little based on the content of an environment variable. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. Huh... duh! Of course! In this case, I object to the way the word works. We *do* "detect" i386 and alpha. The code ought to do something similar to what the i386 and alpha words do. That would make sense. Note that 'vmware' is a subset of 'i386' for whatever that's worth. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenSSH b0rked 6/11
From today's buildworld: [...] cc -O -pipe -DLIBWRAP -DLOGIN_ACCESS -I/usr/src/secure/usr.sbin/sshd/../../../usr.bin/login -DSKEY -c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do_exec_pty': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:651: warning: passing arg 2 of `auth_ttyok' from incompatible pointer type /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do_child': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:866: syntax error before `*' /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: `lc' undeclared (first use in this function) /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: (Each undeclared identifier is reported only once /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: for each function it appears in.) *** Error code 1 Following patch fixes it: Index: session.c === RCS file: /home/src/FreeBSD/src/crypto/openssh/session.c,v retrieving revision 1.5 diff -u -r1.5 session.c --- session.c 2000/06/10 22:32:57 1.5 +++ session.c 2000/06/11 18:52:35 @@ -857,14 +857,15 @@ extern char **environ; struct stat st; char *argv[10]; +#ifdef LOGIN_CAP + login_cap_t *lc; +#endif /* login(1) is only called if we execute the login shell */ if (options.use_login command != NULL) options.use_login = 0; #ifdef LOGIN_CAP - login_cap_t *lc; - lc = login_getpwclass(pw); if (lc == NULL) lc = login_getclassbyname(NULL, pw); -aDe -- Ade Lovett, Austin, TX. [EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Strange rpc.statd and mount_nfs
::- auth_destroy(clp-cl_auth); ::- clnt_destroy(clp); ::retrycnt = 0; ::} ::+ auth_destroy(clp-cl_auth); ::+ clnt_destroy(clp); ::+ so = RPC_ANYSOCK; : : Good catch! This patch looks good to me, I am going to go ahead : and commit it. : : Resetting 'so' is good code form, but I went through the rpc code : and it wasn't an operational bug ... the rpc code can overwrite so : in the case of a failure but only with '-1', which is RPC_ANYSOCK : anyway. Still, it's good not to make assumptions. : : -Matt : :Without the "so = RPC_ANYSOCK" and no other changes, the "weak credential" :failure turned into a "bad file descriptor" failure, so I think the non -1 :socket fd is being reused. Perhaps the initialization of "so" should be moved :into the retry loop. : :Jonathan Hanna [EMAIL PROTECTED] Hmm. Yes, there does appear to be an issue there. The 'goto tryagain' on line 777 is leaving the clp and al_auth allocated as well, so there is a memory leak there too. I'll do a whole cleanup on the code and post a more involved patch. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during boot under current
Brian Somers wrote: In article [EMAIL PROTECTED], Archie Cobbs [EMAIL PROTECTED] writes Brian Somers writes: Also (Mark sits beside me at work), is there anyone else out there that actually runs FreeBSD-current under VMWare (irrespective of the host OS) ? This problem has now been traced down to a bug in the lnc driver, where multiple instances are installed. This surfaced as a result of changes made on 16th May. Specifically, the lnc driver declares NLNC softcs. Mark has an isa style ``device lnc0'' in his config and then uses vmware with two configured devices. Actually, PCI cards allocated their own softc dynamically, only ISA cards accessed the softc array. config kernel produces lnc.h which contains ``#define NLNC 1'' and if_lnc_pci.c dives in and starts writing to the second softc. I'll look at fixing this at some point if you don't have time Paul :-I Just got back from the Perl cruise, still catching up with things. This may have broken because Paul changed the softc decl from static to just global (so that the other if_lnc*.c modules can get at it) either that or Mark has been ``just lucky'' so far and the lnc driver has never worked properly with more than one device. This would neatly It was working with more than one device (one PCI and one ISA) the day I left, which was 19 May. I think the changes to the PCI and ISA compatibility code modified something relating to unit number allocation that caused the ISA driver to get a unit number NLNC whereas before the ISA instances would come first and the PCI instances would get unit numbers after the ISA cards, since the PCI part of the driver creates softc structures dynamically that worked fine. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with PCM and ESS 1868
I was about to post something like this myself. I've got an SBLive and I hear the same pops and clicks during any audio playback (mp3/wav/whatever). It all worked great up until a couple days ago. On Sun, 11 Jun 2000, Donn Miller wrote: The recent commits to PCM, as of a few days back, have given me problems with my ESS 1868. When I play MP3's with mpg123, I get a lot of loud pops and clicks during playback. Otherwise, the MP3s DO play all the way through. However, when I try to play MP3s with Real Player 7, it just hangs at the beginning, and doesn't play the MP3. Before the commits to PCM, I was able to play MP3s OK with Real Player 7. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with PCM and ESS 1868
On Sun, 11 Jun 2000, Donn Miller wrote: The recent commits to PCM, as of a few days back, have given me problems with my ESS 1868. When I play MP3's with mpg123, I get a lot of loud pops and clicks during playback. Otherwise, the MP3s DO play all the way through. However, when I try to play MP3s with Real Player 7, it just hangs at the beginning, and doesn't play the MP3. Before the commits to PCM, I was able to play MP3s OK with Real Player 7. I hate to post a "me-too", but here it goes. I'm also experencing similar problems with pcm on my laptop with the neomagic driver. Running "amp -s" which reports the number of frames written to the sound device, will write about 20 frames, and then hang in the state of [pcmwr] until ctrl-c is pressed. It sounds like theres a DMA transfer problem. Doing something like "cat /kernel /dev/audio" will also just loop the first 1/2 second over and over. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
At 10:47 AM -0700 6/11/00, Mike Smith wrote: It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. For instance, I might be running the vmware program itself under linux, and thus I am doing nothing with a "freebsd port" of vmware. At system startup, vmware is just a (virtual) hardware platform that the OS might want to be aware of. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
setsockopt(IP_FW_ADD)
00050 divert 8668 ip from any to any via dc0 ipfw: setsockopt(IP_FW_ADD): Invalid argument I'm getting this error with ipfw running current as of this morning. Has something changed? Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCM problems (was Re: cvs commit: src/sys/dev/sound/pcm channel.c)
Note: CC list has been trimmed, and moved to -current from -committers
as there are related comments on this issue on -current.
On Sat, Jun 10, 2000 at 07:15:58AM -0700, Jordan K. Hubbard wrote:
I'm also finding that applications like mpg123 don't play audio
anymore whereas that very application does with a May 15th kernel,
that being the most recent "old" kernel I have lying around on this
laptop. If I play a WAV file with waveplay, it works fine. That
does tend to suggest that the speed at which you can cram data down
the audio subsystem's throat is a factor.
- Jordan
On Fri, Jun 09, 2000 at 02:11:29PM -0500, Richard Seaman, Jr. wrote:
If I just cat a .au file into /dev/audio, I get about 1/4 of a second
of plan and then silence, with without the patch.
Your symptoms are different then. Don't know if the cause is the
same.
Thinking about this some more, and as a followup to my last message, here's
what I'm guessing is happening to you.
You fill the device buffers very rapidly. Since chn_wrintr is not getting
called as dma activity occurs, the only time the dma pointers can get updated
and therefore indicate that the buffers aren't full is when you write to
the buffers -- but you can't because they're already marked full. ie.
you're deadlocked. The sound you hear is the dma buffers emptying, but your
app never knows it happened because the buffers are still marked full.
My case is the opposite side of the problem. My app doesn't always fill the
buffers fast enough, and the dma pointers get corruped.
I'd guess that those that don't have problems either a) are getting
dma interrupts, or b) manage to fill the buffers at a rate that is
neither too fast nor too slow.
I don't know if all the reported pcm problems are related. In my case
it appears that the pcm driver expects to get dma interrupts, but isn't
getting them. Don't know if thats a hardware problem that is unique
to my old Gus PnP Pro that I just recently pulled off the scrap heap
and installed. However, a number of the problems others have reported
were reproducable here.
I've been running the attached patch to channel.c in sys/dev/sound/pcm.
With this, I am able to play mp3 files with both mpq123 and RealPlayer7,
wav files with waveplay, and 'cat XXX.au /dev/audio' works fine.
These patches don't solve the lack of dma interrupts, but appear to
work around them. If you are getting dma interrupts, you will get
a flood of "chn_wrintr" messages, and you will probably want to
disable the related printf in this case. Also, your problem in this
case is probably different than mine. Also, the "DEB(x) x" statement
will generate some debugging junk in your log files, so you might
want to comment this out if you don't want it.
I haven't tried these for recording, so I have no idea if they work
for recording. From comments Brian Somers has made, I gather this
will probably still not solve his problems.
I wonder if Cameron Grant could confirm whether the driver expects
dma interrupts in all cases?
--
Richard Seaman, Jr.email:[EMAIL PROTECTED]
5182 N. Maple Lane phone:262-367-5450
Nashotah WI 53058fax:262-367-5852
Index: channel.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v
retrieving revision 1.28
diff -u -r1.28 channel.c
--- channel.c 2000/06/06 22:30:22 1.28
+++ channel.c 2000/06/11 16:25:26
@@ -35,10 +35,10 @@
#define ISA_DMA(b) (((b)-chan = 0 (b)-chan != 4 (b)-chan 8))
#define CANCHANGE(c) (!(c)-buffer.dl)
-/*
+
#define DEB(x) x
-*/
-static void buf_clear(snd_dbuf *b, u_int32_t fmt, int length);
+
+static void buf_clear(snd_dbuf *b, u_int32_t fmt, int start, int length);
static void chn_dmaupdate(pcm_channel *c);
static void chn_wrintr(pcm_channel *c);
static void chn_rdintr(pcm_channel *c);
@@ -187,15 +187,20 @@
hwptr = chn_getptr(c);
if (c-direction == PCMDIR_PLAY) {
delta = (b-bufsize + hwptr - b-rp) % b-bufsize;
+ buf_clear(b, b-fmt, b-rp, delta);
b-rp = hwptr;
b-rl -= delta;
b-fl += delta;
-
if (b-rl 0) {
+ b-rl = 0;
+ b-fl = b-bufsize;
+ }
+ if (b-rl 0) {
DEB(printf("OUCH!(%d) rl %d(%d) delta %d bufsize %d hwptr %d
rp %d(%d)\n", chn_updatecount++, b-rl, b_rl, delta, b-bufsize, hwptr, b-rp, b_rp));
}
} else {
delta = (b-bufsize + hwptr - b-fp) % b-bufsize;
+ buf_clear(b, b-fmt, b-fp, delta);
b-fp = hwptr;
b-rl += delta;
b-fl -= delta;
@@ -233,7 +238,7 @@
b-fl = b-bufsize - b-rl;
b-underflow = 0;
} else {
- /* chn_dmaupdate(c); */
+ chn_dmaupdate(c);
Re: setsockopt(IP_FW_ADD)
On Sun, Jun 11, 2000 at 01:19:44PM -0700, Edwin Culp wrote: 00050 divert 8668 ip from any to any via dc0 ipfw: setsockopt(IP_FW_ADD): Invalid argument I'm getting this error with ipfw running current as of this morning. Has something changed? Other than that you forgot options IPDIVERT in your kernel? -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setsockopt(IP_FW_ADD)
00050 divert 8668 ip from any to any via dc0 ipfw: setsockopt(IP_FW_ADD): Invalid argument I'm getting this error with ipfw running current as of this morning. Has something changed? well, there was a commit to dummynet few days ago, which requires you to recompile ipfw. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setsockopt(IP_FW_ADD)
Will Andrews wrote: On Sun, Jun 11, 2000 at 01:19:44PM -0700, Edwin Culp wrote: 00050 divert 8668 ip from any to any via dc0 ipfw: setsockopt(IP_FW_ADD): Invalid argument I'm getting this error with ipfw running current as of this morning. Has something changed? Other than that you forgot options IPDIVERT You're right. I took out all my IPFIREWALL options to use the kldmodule ipfw.ko. I didn't realize that the IPDIVERT option was still needed. Thanks, I'll recompile as soon as I finish a new cvsup and can see why I'm getting a coda message with config kernel ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard The fun never stops:-) Thanks again, ed in your kernel? -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setsockopt(IP_FW_ADD)
Luigi Rizzo wrote: 00050 divert 8668 ip from any to any via dc0 ipfw: setsockopt(IP_FW_ADD): Invalid argument I'm getting this error with ipfw running current as of this morning. Has something changed? well, there was a commit to dummynet few days ago, which requires you to recompile ipfw. Luigi, Thanks a lot. It appears to have been a not very smart, oversite:-) when changing my kernel config. thanks again, ed cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Newmidi Release Candidate is ready
-On [2611 15:16], Seigo Tanimura ([EMAIL PROTECTED]) wrote: The release candidate of newmidi is finally ready. The patch for -current can be found at: URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz I will put this patch into the final test stage of 1 month. The date of merge is hence going to be 11th July 2000. Few nits: mss.c: gusc.h isn't in this file anymore, this causes a reject. Also, NMIDI 0 type of constructs are not needed anymore with 4.0 and higher IIRC. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Laat ons drinken op ons grote ongelijk... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Wed, 7 Jun 2000, Kris Kennaway wrote: :This patch was developed by Peter Jeremy and myself and increases the :number of possible temporary filenames which can be generated by the :mktemp() family, by more densely encoding the PID and using a larger set :of characters to randomly pad with. : :Instead of using only alphabetic characters, the patch uses the following :character set: : :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ ":" is path seperator in Apple's HFS filesystem. "@" is used as the line erase character in some shells. "#" is rubout in some shells. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sshd unbroken
Sorry for the world breakages, all, it turns out I was a bit eager to commit a security fix. World should be compilable again now (at least, if it breaks it should hopefully not be my fault :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(thoughts on) the mktemp() patch.
Maybe the soltion is to think out of the box. Maybe temporary filestore should be a more official OS service. Race conditions would be far less common if the OS itself was managing the namespace. You might even expand the capability somewhat. Provide process local, uid local and global namespaces. You'd even gain the ability to specify the limits on temporary filestore. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Worst case swapping.
I'm running a 700Mhz K7 with 256M of RAM as my workstation. I have two fast SCSI drives with a Gig of swap between them. The system shouldn't normally be a bottleneck as a workstation. I find, however, that there seem to be some bad worst-case senerios popping up rather often. Netscape is a good (common) example, but other memory stresses will show if the system is busy, too. What I'm talking about is a situation where some portion of the application will be swapped out and then when the application becomes active again, the swap will grind heavily reading and writing for 10-20 seconds (pushing 5M/s out and 5M/s in). Now the application in question (Netscape) usually runs around 50 to 75 megs, so that swapping activity is effectively swapping an amount of memory equavalent to the whole application out and then in again. My fear that this is a worst case scenario comes from this fact: that some other part of the application now-just-recently-active-again is being swapped out to bring in a part that was already swapped out. Now, you could argue that this case is hard to avoid, but I find this happening during periods of constant browsing ... such that only a small amount of the application could have been out. I'm positive that its not a case of the working set being larger than physical memory; it's one of choice of page to swap. Has anyone done any thinking about this behaviour? It occurs with varying degree to many applications. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Worst case swapping.
"Matthew" == Matthew Dillon [EMAIL PROTECTED] writes: Matthew :Now the application in question (Netscape) usually runs Matthew around 50 to :75 megs, so that swapping activity is Matthew effectively swapping an amount Matthew 50-75MB is a lot, but if you have 256MB of ram it can't Matthew be the cause unless there are other active things eating Matthew similar amounts of ram. Matthew It kinda sounds like a runaway to me. A ps axl during Matthew these heavy paging periods should shed some light on the Matthew problem. Believe me, I look at these things. Yes there is a lot going on and a lot using memory. I normally have about 20% to 25% of my Gig of swap used... meaning that I have allocated roughly double my RAM in applications. And when this worst-case happens, memory is full... but the only active application is Netscape. On my home machine, the same thing tends to happen. It only has 128M and vastly fewer things going on. I see cases were I'm surfing for 20-30 minutes and I will hit this 10 to 30 second (longer, becase the swap at home is slower) gap in netscape response. The only other applications running would be something like a small UUCP transfer or a small amount of NFS traffic when the wife's (diskless) machine changes screensavers. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
David Scheidt wrote: On Wed, 7 Jun 2000, Kris Kennaway wrote: :This patch was developed by Peter Jeremy and myself and increases the :number of possible temporary filenames which can be generated by the :mktemp() family, by more densely encoding the PID and using a larger set :of characters to randomly pad with. : :Instead of using only alphabetic characters, the patch uses the following :character set: : :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ ":" is path seperator in Apple's HFS filesystem. "@" is used as the line erase character in some shells. "#" is rubout in some shells. # is a comment ~ at the beginning is a ~username ^ is an alias for | in old shells These could matter in the light of mktemp(1). file=`mktemp foo.` Why 74 characters? Why not 64? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sun, 11 Jun 2000, Peter Wemm wrote: These could matter in the light of mktemp(1). file=`mktemp foo.` You guys are responding to old messages..I've already changed my mind about this. Why 74 characters? Why not 64? The more characters we have in the sample set the larger the namespace and the better the statistical protection afforded by mktemp() Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
:You guys are responding to old messages..I've already changed my mind :about this. : : Why 74 characters? Why not 64? : :The more characters we have in the sample set the larger the namespace and :the better the statistical protection afforded by mktemp() : :Kris There's reasonable, and there's overkill. mktemp() has no business using punctuation in the temporary file names. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with PCM and ESS 1868
my SBLive just wont play any mp3. it just simplye stop immediantly. It was ok before my recent make world. On Sun, 11 Jun 2000, Donn Miller wrote: The recent commits to PCM, as of a few days back, have given me problems with my ESS 1868. When I play MP3's with mpg123, I get a lot of loud pops and clicks during playback. Otherwise, the MP3s DO play all the way through. However, when I try to play MP3s with Real Player 7, it just hangs at the beginning, and doesn't play the MP3. Before the commits to PCM, I was able to play MP3s OK with Real Player 7. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Worst case swapping.
:Believe me, I look at these things. Yes there is a lot going on and a :lot using memory. I normally have about 20% to 25% of my Gig of swap :used... meaning that I have allocated roughly double my RAM in :applications. : :And when this worst-case happens, memory is full... but the only :active application is Netscape. : :On my home machine, the same thing tends to happen. It only has 128M :and vastly fewer things going on. I see cases were I'm surfing for :20-30 minutes and I will hit this 10 to 30 second (longer, becase the :swap at home is slower) gap in netscape response. : :The only other applications running would be something like a small :UUCP transfer or a small amount of NFS traffic when the wife's :(diskless) machine changes screensavers. : :Dave. Hmm. How large a memory-cache do you have configured for netscape? Disk cache? What is the RSS and VSZ of the netscape binary while the paging is going on? Please post a ps axl of the state of the system while the paging is going on. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Worst case swapping.
Matthew Dillon wrote: :Believe me, I look at these things. Yes there is a lot going on and a :lot using memory. I normally have about 20% to 25% of my Gig of swap :used... meaning that I have allocated roughly double my RAM in :applications. : :And when this worst-case happens, memory is full... but the only :active application is Netscape. : :On my home machine, the same thing tends to happen. It only has 128M :and vastly fewer things going on. I see cases were I'm surfing for :20-30 minutes and I will hit this 10 to 30 second (longer, becase the :swap at home is slower) gap in netscape response. : :The only other applications running would be something like a small :UUCP transfer or a small amount of NFS traffic when the wife's :(diskless) machine changes screensavers. : :Dave. Hmm. How large a memory-cache do you have configured for netscape? Disk cache? What is the RSS and VSZ of the netscape binary while the paging is going on? Please post a ps axl of the state of the system while the paging is going on. Netscape reallys goes to pot in a hurry if you allow it to use more than 1-2MB of memory cache. A friend was seeing a terrible response and tracked it back to Netscape's memory cache. He had a lot of memory and started out with something on the order of 16MB. By the time he was satisfied he was allowing less than ~2MB of memory cache, which is all I had ever allowed it to use. I seem to remember an affect on how much disk cache but that part of the memory has evaporated. Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Worst case swapping.
Kent Stewart drunkenly mumbled... Netscape reallys goes to pot in a hurry if you allow it to use more than 1-2MB of memory cache. A friend was seeing a terrible response and tracked it back to Netscape's memory cache. He had a lot of memory and started out with something on the order of 16MB. By the time he was satisfied he was allowing less than ~2MB of memory cache, which is all I had ever allowed it to use. i never screwed with the memory cache, but i've seen some pretty heavy memory leakage with navigator. how long have you had netscape running? an hour, a day, a week? my experience (it seems to have gotten better lately since the upgrade to 4.0 however) has seen starting size 16M, ending size 172M, running time of 13 days. of course, the fact that netscape actually ran for 13 days without crashing is a bit of a miracle itself. :) cheers, -brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: static linked files in /usr/bin
On Sun, Jun 11, 2000 at 09:00:34PM +0400, Juriy Goloveshkin wrote: Why a lot of files in /usr/bin(sbin) are static linked? for example, tar: static - 272832 bytes(83416 dynamic) IMO tar should live in /bin as it is used to restore a system from tape. I don't know why ``dump'' is in /usr/sbin -- only restore should be there. /usr/bin/tar is statically linked so it isn't depended on /usr/lib/ which may be terribly broken (and thus why you are doing a restore). is it magic of /usr/src/gnu folder? Has nothing to do with it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.x buildworlds broken on -current
On Sun, Jun 11, 2000 at 04:43:41PM +1000, Bruce Evans wrote: Building old kernels under -current is becoming difficult. I build kernels for RELENG_3 and RELENG_4. This causes a lot of new warnings about invalid assembler, but still works, at least a week ago. Don't worry, the plan is to bring Bintuils 2.10 to 4-STABLE once I can setup a suffient testing environment. As far the assembly cleanup, that's really jhb's area. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VT520 support
Does FreeBSD support the vt520? I've looked around in documentation, but haven't been able to find anything about it. If it isn't yet, I could probably get my hands on a spare (note single, not plural) if someone is seriously interested in supporting it. TIA. -Otter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Worst case swapping.
On Sun, 11 Jun 2000, Brian Hechinger wrote: :Kent Stewart drunkenly mumbled... : : Netscape reallys goes to pot in a hurry if you allow it to use more : than 1-2MB of memory cache. A friend was seeing a terrible response : and tracked it back to Netscape's memory cache. He had a lot of memory : and started out with something on the order of 16MB. By the time he : was satisfied he was allowing less than ~2MB of memory cache, which is : all I had ever allowed it to use. : :i never screwed with the memory cache, but i've seen some pretty heavy memory :leakage with navigator. how long have you had netscape running? an hour, a Netscape has lots of memory leaks. the worst seem to be in Javascript, with java being a close second. I find I get the best performance and stability out of it if I leave those off, except when you need them. I also keep the memory cache size small, 2 or 3 megs; I leave the disk cache at a large size, since I am behind a slow link. The FreeBSD buffer caching does a good job of not throwing stuff away that I am actually using, so that works out quite well. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VT520 support
On Mon, 12 Jun 2000, Otter wrote:
Does FreeBSD support the vt520? I've looked around in documentation,
but haven't been able to find anything about it. If it isn't yet, I could
probably get my hands on a spare (note single, not plural) if someone is
seriously interested in supporting it. TIA.
-Otter
I don't see an entry in termcap.src,v1.90 under HEAD for vt520. However,
it is in esr's v11.0.1 of the termcap.src file. This file is copyrightless
and appears 100% compatible with the current termcap. Is there any
reason it is not merged in regularly? Regardless, here is the termcap
entry for a vt520 in the termcap syntax:
vt520|DEC VT520:\
:am:mi:xn:xo:\
:co#80:li#24:vt#3:\
:*6=\E[4~:@0=\E[1~:RA=\E[?7l:\
:S5=\E[?0;0r\E\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:\
:SA=\E[?7h:\
:ac=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\
:ae=\E(B:al=\E[L:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:\
:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:\
:dc=\E[P:dl=\E[M:do=\E[B:ei=\E[4l:ho=\E[H:\
:i2=\E[?67h\E[64;1"p:if=/usr/share/tabset/vt300:\
:im=\E[4h:is=\E[1;24r\E[24;1H:k0=\E[29~:k1=\EOP:k2=\EOQ:\
:k3=\EOR:k4=\EOS:k5=\E[17~:k6=\E[18~:k7=\E[19~:k8=\E[20~:\
:k9=\E[21~:k;=\E[29~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:\
:kb=^H:kd=\E[B:kl=\E[D:kr=\E[C:ku=\E[A:le=^H:mb=\E[5m:\
:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:r3=\E[?67h\E[64;1"p:\
:rc=\E8:rf=/usr/share/tabset/vt300:sc=\E7:se=\E[m:sf=\ED:\
:so=\E[7m:sr=\EM:ta=^I:ue=\E[m:up=\E[A:us=\E[4m:
Brandon D. Valentine
--
"You should believe in death, taxes, Larry Ellison's loathing of Bill
Gates and Intel's inability to ship a working chipset."
- Dr Spinola, The Register, 05/13/2000
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
