Re: HEADS UP: rc.d is in the tree
On Fri, 14 Jun 2002 16:55:40 +0300 Danny Braniss [EMAIL PROTECTED] wrote: in amd, # REQUIRE: rpcbind mountall ypbind nfsclient ** since i don't use yp, how can i override this? or in other words, can REQUIRE be configurable too? The REQUIRE line doesn't mean it will be started. It just means that ypbind comes before amd in the boot process. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Thu, 13 Jun 2002 15:37:55 -0700 (PDT) Gordon Tetlow [EMAIL PROTECTED] wrote: I've imported the excellent work by Mike Makonnen into the tree. Please note that it should be fully functional but there are some parts that need some looking at: atm ipfilter some others that I'm forgetting Hopefully Mike will chime in with some others. I've been having some problems with named not starting properly since I synced up all the scripts with the NetBSD bits. I'm not sure exactly what it is, that it doesn't like (the order in which it was started changed), but I'll be taking a look at it in a bit. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Tue, 11 Jun 2002 04:36:41 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: This solution has the advantage that the only code that has to change is the ucred and setuid/gid helper functions that already know about the struct uidinfo functions. In fact only three functions not related to uidinfo(9) need to be touched: proc0_init(), change_ruid(), change_uid(). The disadvantage is the memory bloat and a small amount of code complexity (but as I said, this is localized, and not very complex either). Do you like it? Should I go ahead and implement a patch? Anything I overlooked? It won't work if you have to change a uidinfo more than once. I still prefer just doing the uifind() at the beginning of the function, passing in the uidinfo pointer to the chnage_fooid() functions, and adding cleanup uifree's in case of failure. Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. With that assumption in mind I wanted to compartmentalize the allocation of struct uidinfo. It seemed cleaner to me to have only uifind() and its immediate callers have intimate knowledge struct uidinfo creation and destruction, but I suppose if setuid() (for example) knows enough to compare cr_ruid et al, its knowledge of one more member isn't that bad. Basically, I wanted to avoid having to touch every function that changes the r/e uid, and touch just those that already dealt with the uidinfo. In any case, I'll submit a patch to you doing it the way you suggested. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Tue, 11 Jun 2002 13:07:03 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. Oh, duh, you are right, it should work then. You can implement whichever you please then. I can see pros and cons cleanliness-wise of both. :) Disregard my earlier patch. It has a bug. Is it possible to sleep when doing a FREE()? I had assumed not, but it seems I may be mistaken. On which way to go: I like your idea better, because it is less work and less bloat. Sometimes I have to keep reminding myself: Choose the simplest design that works. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Sat, 08 Jun 2002 10:57:32 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Is the solution to this to use M_NOWAIT and continue re-trying untill it succeeds? Is there on-going smp work in locking down struct proc that will eliminate this problem? Well, the real solution probably involves changing where we dink with uidinfo structs so we bump the reference count on teh new one before we grab the proc lock, change over to the new one while holding the proc lock, then release the reference to the old one after we are done. Well... this is basically what happens setuid - creates a new ucred - locks p - calls change_ruid() change_ruid - calls uifind() uifind - does MALLOC w/ M_WAITOK After thinking about it for a while, this is the solution I came up with: Each new struct ucred will carry an array of pointers to struct uidinfo. This will be an array of 3 elements (a spare for cr_ruidinfo, cr_uidinfo, null). Obviously, it gets added after -cr_endcopy. When crget() is called it calls a function whose job it is to create an array of pointers to struct uidinfo and allocate the memory for them. When uifind() is called it will be given an array of pointers to uidinfo structs (the ones from ucred), in addition to the uid it is to lookup. If it already has a uidinfo for that uid, then it returns that to the calling function. If it can't find the uid, then it unhooks (copies the address, and deletes it from the array) the last struct uidinfo from the array, initializes it, inserts it into the hashtable and returns it to the caller. When crfree is called it calls a function that deallocates the spare structs uidinfo. This solution has the advantage that the only code that has to change is the ucred and setuid/gid helper functions that already know about the struct uidinfo functions. In fact only three functions not related to uidinfo(9) need to be touched: proc0_init(), change_ruid(), change_uid(). The disadvantage is the memory bloat and a small amount of code complexity (but as I said, this is localized, and not very complex either). Do you like it? Should I go ahead and implement a patch? Anything I overlooked? Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fixing could sleeep... was (Re: ../../../vm/uma_core.c:1327: couldsleep with pcm0:play:0 locked from)
On Sat, 08 Jun 2002 04:03:40 -0700 (PDT)
Hiten Pandya [EMAIL PROTECTED] wrote:
--- Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] wrote:
../vm/uma_core.c:1160
../../../vm/uma_core.c:1327: could sleep with process lock locked
from ../../../kern/kern_prot.c:511
../../../vm/uma_core.c:1327: could sleep with process lock locked
from
Hope this help. Do you think these errors are alarming ?
I mean, do you recommend me to recopile my kernel again ?
(please noo, it takes me a lot of time to recompile whatever
thing :)
I also get these and I figured they're as good an excuse as any to jump
into the kernel code :-} This particular one (and others related to the
setuid/gid family of functions) occur because some time after PROC_LOCK
is called in set{uid,euid} and further down the call stack uidfind()
allocates some memory specifying the M_WAITOK flag.
Is the solution to this to use M_NOWAIT and continue re-trying untill it
succeeds? Is there on-going smp work in locking down struct proc that
will eliminate this problem?
Cheers,
Mike Makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Weekly run output: makewhatis
I started getting these recently in my weekly run outputs. Cleaning up kernel database files: Rebuilding locate database: Rebuilding whatis database: makewhatis: /usr/local/man/man1/etags.1.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_8859_to_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_enable_translation.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_set_string_translators.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_t61_to_8859.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_translate_from_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_translate_to_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2id2children.8.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2id2entry.8.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2index.8.gz: No such file or directory -- End of weekly output -- I know the etags line has been happening for at least a couple of months, but all the rest are new. Is this a result of the recent de-perlifying of makewhatis? I'm assuming there's probably a missing 2/dev/null somewhere. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_witness.c
On Sat, 08 Jun 2002 10:57:31 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Heh, that's fine. Let me know if it works. :) Ok, no more exhausted messages. Before I applied it I had a bunch of dead witnesses when I did a show witness in ddb (i.e. - only about 1 out of 10 witnesses were _not_ dead). I didn't see any after the patch (I assume I'll probably see more as my uptime increases?). Before which patch? The one in CVS or the one I haven't committed yet. (The one I posted that's not in CVS has a bug btw). The one in CVS. Cheers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rc.d boot scripts are ready
Ok folks, I have our current rc.* scripts ported to the NetBSD framework. Preliminary testing says it's good to go, so consider this an official call for testers. Gordon has indicated he is ready to start committing it soon. I ask that people start testing it out before he does so. That will enable me to get any remaining bugs fixed before it hits the tree. Once you download and follow the directions at: http://home.pacbell.net/makonnen/rcng.html you can enable it by including rc_ng=YES in your /etc/rc.conf. If you experience any breakage please let me know so I can fix it. I'd appreciate it if people with the appropriate setups especially test the following: ATM ipfilter amd Any comments, constructive criticism welcome. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc.d boot scripts are ready
[ forgive this breach of net-ettiquette, but this should probably be given a wider audience] On Thu, 06 Jun 2002 05:01:18 -0600 Mike Makonnen [EMAIL PROTECTED] wrote: Ok folks, I have our current rc.* scripts ported to the NetBSD framework. Preliminary testing says it's good to go, so consider this an official call for testers. Gordon has indicated he is ready to start committing it soon. I ask that people start testing it out before he does so. That will enable me to get any remaining bugs fixed before it hits the tree. Once you download and follow the directions at: http://home.pacbell.net/makonnen/rcng.html you can enable it by including rc_ng=YES in your /etc/rc.conf. If you experience any breakage please let me know so I can fix it. I'd appreciate it if people with the appropriate setups especially test the following: ATM ipfilter amd Any comments, constructive criticism welcome. Cheers, Mike Makonnen 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
current.freebsd.org
I have been trying for several days now to access current.freebsd.org so I can get the latest -CURRENT snapshot instead of my usual DP1 - cvsup - buildworld, but I am unable to get in.. Is this not a public server? saturn# ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:sturdee): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machine/endian.h revision 1.33 breaks port x11-fm/gentoo
Andrea Campi [EMAIL PROTECTED] writes: There's a problem with coldsync port on -current which has to do with endian macros: cc -Wall -ansi -pedantic -O -pipe -march=pentiumpro -DHAVE_CONFIG_H -I. -I./.. - I./../include -I/usr/local/include -c PConnection_net.c In file included from /usr/include/arpa/nameser.h:446, from PConnection_net.c:11: /usr/include/arpa/nameser_compat.h:54: syntax error before string constant /usr/include/arpa/nameser_compat.h:82: duplicate member `rd' /usr/include/arpa/nameser_compat.h:83: duplicate member `tc' /usr/include/arpa/nameser_compat.h:84: duplicate member `aa' /usr/include/arpa/nameser_compat.h:85: duplicate member `opcode' /usr/include/arpa/nameser_compat.h:86: duplicate member `qr' /usr/include/arpa/nameser_compat.h:88: duplicate member `rcode' /usr/include/arpa/nameser_compat.h:89: duplicate member `cd' /usr/include/arpa/nameser_compat.h:90: duplicate member `ad' /usr/include/arpa/nameser_compat.h:91: duplicate member `unused' /usr/include/arpa/nameser_compat.h:92: duplicate member `ra' In file included from PConnection_net.c:12: /usr/include/resolv.h:130: field `in6a' has incomplete type *** Error code 1 Anybody cares to have a look? Hmm, the application thinks it conforms to POSIX, but uses headers not defined in POSIX. Removing: #ifndef _POSIX_C_SOURCE # define _POSIX_C_SOURCE 2 #endif /* _POSIX_C_SOURCE */ ...from config.h will probably fix it. I may just change all the headers over to _BYTE_ORDER and friends, so that even confussed applications work. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machine/endian.h revision 1.33 breaks port x11-fm/gentoo
[Sorry I missed the beginning of this thread.] Niels Chr. Bank-Pedersen [EMAIL PROTECTED] writes: On Sun, May 19, 2002 at 12:32:07AM +0200, Oliver Braun wrote: Hi, I am the ports maintainer of x11-fm/gentoo. Building gentoo dies since revision 1.33 of machine/endian.h with the following error: In file included from cmdseq.c:18: /usr/include/sys/wait.h:114: duplicate member `w_Filler' /usr/include/sys/wait.h:115: duplicate member `w_Retcode' /usr/include/sys/wait.h:116: duplicate member `w_Coredump' /usr/include/sys/wait.h:117: duplicate member `w_Termsig' /usr/include/sys/wait.h:132: duplicate member `w_Filler' /usr/include/sys/wait.h:133: duplicate member `w_Stopsig' /usr/include/sys/wait.h:134: duplicate member `w_Stopval' *** Error code 1 With machine/endian.h revision 1.32 it works. A workaround for x11-fm/gentoo is to declare the functions needed explicit and avoid including whole sys/wait.h. This is good. I was hoping fixing the namespace pollution in endian.h would expose more bugs. The bug in this case is that wait.h is depending on the old pollution of endian.h in the !__BSD_VISIBLE case. The solution is to use the underscored variants in wait.h. I'll commit the fix soon. I ran into another build problem later on. This time the bug was in the port itself. It was missing a string.h include, for the strdup() prototype. I think the previous GCC didn't complain about missing prototypes for built-ins, which is probably why this wasn't exposed earlier. Adding the include doesn't fix the problem because the program, via gentoo.h, specifies that it wants a POSIX environment (`#define _POSIX_C_SOURCE 3'). I think the value 3 is wrong here. The correct format is MM, which specifies the ratified date of the Standard. Nevertheless, our headers try and accomodate and provide a 1988 environment. strdup() wasn't added to POSIX until 2001. The solution would be to specify a Standard that provides the interface the application needs, or to not specify a Standard at all. The software does the latter in the NetBSD, et al cases. This patch below and the upcoming commit to sys/wait.h should fix this port. %%% --- gentoo.h.orig Sun May 26 19:20:42 2002 +++ gentoo.hSun May 26 19:13:52 2002 @@ -13,7 +13,7 @@ #include config.h -#if !(defined __osf__ defined __alpha__) !defined __NetBSD__ +#if !(defined __osf__ defined __alpha__) !defined __NetBSD__ !defined +__FreeBSD__ #define __EXTENSIONS__ #define _POSIX_C_SOURCE3 /* This is for Solaris. */ #definePOSIX_C_SOURCE3 %%% Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: strtod sscanf on -CURRENT?
Chris Hedley [EMAIL PROTECTED] writes: On Fri, 24 May 2002, Igor Roboul wrote: Maybe I'm wrong, but I think that sscanf on -CURRENT does not work as expected. Interestingly I had some aggro with both scanf and strtod returning somewhat random results recently (about 5th/6th May); I'm afraid I no longer have the results or test programs but I ended up having to hack my own routine together to get a reliable input. What I seem to recall is that scanf didn't return the correct result at all, whereas strtod was okay for the first couple of invocations within the same program, after which it began to return garbage (I'm pretty confident that my program didn't have a buffer overrun, it was a fairly short simple effort) Would it be possible for you to reproduce the source to a small program that demonstrates the problem? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
On Thu, 2002-05-09 at 07:41, Mark Murray wrote: On Thu, 2002-05-09 at 03:57, Mark Murray wrote: /usr/sbin/rmuser Wrapper round pw userdel? I took this one while the discussion was going on the past couple of days. It's at: http://home.pacbell.net/makonnen/rmuser.sh It also implements new functionality-- you can now specify a list of usernames on the command line or in a file (-f option) instead of deleting them one at a time. I guess I might as well take adduser too. Manpages too, please! :-) If you don't know *roff, no problem, write the words, and our friedly and excellent docs people will mark it up for you. The problem with writing man pages is, if you don't do it often enough you keep having to relearn it every time you do (which is why I wised up after about the third time or so this happened to me I created a cheat sheet). What would be cool is if the man pages were somehow integrated into the FreeBSD Documentation Project. That way I have to remember only the SGML tags. (yes, yes, I know: patches please? 8-) In any case, here's a proper patch (man page and all): http://home.pacbell.net/makonnen/rmuser.diff Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
On Fri, 2002-05-10 at 02:56, David O'Brien wrote:
On Fri, May 10, 2002 at 01:56:16AM -0600, Mike Makonnen wrote:
The problem with writing man pages is, if you don't do it often enough
you keep having to relearn it every time you do (which is why I wised up
/usr/share/examples/mdoc/example.{1,3,4}
Thanks! I should have guessed.
Cheers,
Mike Makonnen.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: new expr(1) behaviour breaks libtool
John Hay [EMAIL PROTECTED] writes: I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( I'm almost positive this issue was discussed before. Check the follow ups to the commit. The place where I noticed it was when libtool started to complain when compiling jade. Libtool does things like: expr -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -lsp : -l\(.*\) expr -lm : -l\(.*\) expr -lgrove : -l\(.*\) On -current this now have to be: expr -- -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -- -lsp : -l\(.*\) expr -- -lm : -l\(.*\) expr -- -lgrove : -l\(.*\) If we are going to leave this behaviour, we will have to teach libtool how to call expr(1) differently on -stable and -current and it looks like yet again different from the rest of the world. :-((( This should exactly match the behavior of any certified UNIX system. Yes, I did read the commit message, but I still think the behaviour of the new expr(1) is wrong. Not according to the Standard, or the response from Garrett's request for clarification of the Standard. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken?
John Baldwin [EMAIL PROTECTED] writes: I've seen this twice now on both alpha and sparc64. It looks to be related to the ENDIAN macro changes: [...] I guess all of those symbols are not defined or something and so have values of 0 and 0 == 0? sys/wait.h includes machine/endian.h right before it defines this union, so something must be broke in there. Yes, sys/cdefs.h wasn't being included on some archs. It should be fixed now. Sorry about the breakage. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Ruslan Ermilov [EMAIL PROTECTED] writes:
I see the same breakage here.
The breakage has nothing to do with -Werror. Recent commit by
Mike Barcroft to sys/*/endian.h is the culprit.
But the actual problem is with gdb. After a lot of experimenting
I've found that contrib/gdb.291/gdb/defs.h includes nm.h
(gnu/usr.bin/binutils/gdb/${MACHINE_ARCH}/nm.h) which are too
different between i386 and alpha. In the i386 case, nm.h
includes sys/types.h which exposes __BSD_VISIBLE (see how
these affect the *_ENDIAN macros in sys/*/endian.h). But not
in the alpha case. Applying this patch exposes the same bug
on i386:
[...]
David added sys/types.h to src/gnu/usr.bin/binutils/gdb/alpha/nm.h
19 hours ago, so the problem should no longer exist. I won't know for
another three hours (when my alpha is finished buildworld).
The solution is to fix defs.h:
%%%
Index: defs.h
===
RCS file: /home/ncvs/src/contrib/gdb.291/gdb/defs.h,v
retrieving revision 1.3
diff -u -p -r1.3 defs.h
--- defs.h11 Apr 2001 16:15:19 - 1.3
+++ defs.h12 Apr 2002 13:53:37 -
@@ -841,6 +841,8 @@ extern void free ();
#ifdef HAVE_ENDIAN_H
#include endian.h
+#else
+#include sys/types.h
#endif
#if !defined (BIG_ENDIAN)
%%%
I think machine/endian.h would be better here. It may not have
worked because of the missing sys/cdefs.h issue.
Sorry about the breakage.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
David O'Brien [EMAIL PROTECTED] writes: On Fri, Apr 12, 2002 at 12:12:12PM -0400, Mike Barcroft wrote: I think machine/endian.h would be better here. It may not have worked because of the missing sys/cdefs.h issue. We will never get that header included in the GDB sources -- it is totally FreeBSD (NetBSD also?) specific. It almost sounds like we have a bug in our headers. Sort of. The way it historically built was by taking advantage of the fact that C allows multiple #define's if they are the same. My commit changed the definition of BYTE_ORDER to _BYTE_ORDER instead of LITTLE_ENDIAN or BIG_ENDIAN. The reason this didn't show up as a problem on i386 was because of a sys/types.h include (which includes machine/endian.h) earlier in the source file. machine/endian.h (apparently this is spelled endian.h on other systems) should always be included before fiddling with the byte order manifest constants. Your commit which included sys/types.h on alpha fixed this problem in the same way the i386 case is fixed. Where fixed is defined as a side-effect of fixing another problem. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Mike Barcroft [EMAIL PROTECTED] writes: Sort of. The way it historically built was by taking advantage of the fact that C allows multiple #define's if they are the same. My commit changed the definition of BYTE_ORDER to _BYTE_ORDER instead of LITTLE_ENDIAN or BIG_ENDIAN. Just a little correction. The problem is my commit changed the definition of BIG_ENDIAN from 4321 to _BIG_ENDIAN (which is defined as 4321). Similarly for LITTLE_ENDIAN. The BYTE_ORDER macro isn't touched in defs.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdefs and XFree86
Paul Richards [EMAIL PROTECTED] writes: The recent changes to /usr/include/sys/cdefs.h have broken the build of XFree86-Server. The problem is with the _XOPEN_SOURCE macro. At line cdefs.h it's checked i.e. #if _XOPEN_SOURCE = 600 but in XFree86 it's defined as #define _XOPEN_SOURCE Peter fixed this a day or so ago; see rev 1.51. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LINT/NOTES broken after recent bktr(4) change
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/work/src/sys -I/work/src/sys/dev -I/work/src/sys/contrib/dev/acpica -I/work/src/sys/contrib/ipfilter -I/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue /work/src/sys/dev/bktr/bktr_i2c.c /work/src/sys/dev/bktr/bktr_i2c.c: In function `bt848_i2c_attach': /work/src/sys/dev/bktr/bktr_i2c.c:87: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:92: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:93: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:101: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:103: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c: In function `bt848_i2c_detach': /work/src/sys/dev/bktr/bktr_i2c.c:113: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:119: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:119: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:122: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:122: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c: In function `bti2c_smb_callback': /work/src/sys/dev/bktr/bktr_i2c.c:132: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:141: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:142: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:149: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:150: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c: In function `bti2c_iic_callback': /work/src/sys/dev/bktr/bktr_i2c.c:165: structure has no member named `i2c_sc' /work/src/sys/dev/bktr/bktr_i2c.c:174: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:175: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:182: dereferencing pointer to incomplete type /work/src/sys/dev/bktr/bktr_i2c.c:183: dereferencing pointer to incomplete type *** Error code 1 I think I've narrowed down the problem: : revision 1.20 : date: 2002/03/23 15:47:08; author: nsouch; state: Exp; lines: +112 -192 : Major rework of the iicbus/smbus framework: : : - VIA chipset SMBus controllers added : - alpm driver updated : - Support for dynamic modules added : - bktr FreeBSD smbus updated but not tested ^ : - cleanup Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
subscribe _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
Joel Wilsson [EMAIL PROTECTED] writes: On Fri, Mar 08, 2002 at 08:59:53AM -0600, David W. Chapman Jr. wrote: As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. It works if you don't use objprelink, and then change a bunch of files to include arpa/inet.h htonl()/htons()/ntohl()/ntohs() can be defined by including arpa/inet.h, netinet/in.h, or sys/param.h (the first two are POSIX-required, the final one is temporary until the base system no long requires it). Previously these functions were leaked to all sorts different headers. Weak aliases exist for these functions so even if software depended on, for instance ntohl() being prototyped sys/types.h, this should not be fatal. There's a few small issues with the prototypes which can lead to some compiler diagnostics (this should be fixed by Sunday). If someone can provide a compiler error and source file, I can figure out what the problem is. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
[ Could we CC a few more lists? I'm not sure everyone that uses FreeBSD has read this yet. :) ] David W. Chapman Jr. [EMAIL PROTECTED] writes: Its not related to libpng, I believe that has been fixed, but I cannot tell for sure because kde cannot be compiled under -current. I'm not the only one that is experiencing it either, here is what I was told by Alan Eldridge [EMAIL PROTECTED] On Tue, Mar 05, 2002 at 05:26:27PM -0600, David W. Chapman Jr. wrote: When I try to build kdelibs2 I get the following under recent -current builds ,.deps/kextsock.pp -c kextsock.cpp -fPIC -DPIC -o .libs/kextsock.o kextsock.cpp: In method `struct kde_addrinfo * KExtendedSocketLookup::results()' : kextsock.cpp:294: implicit declaration of function `int __htons(...)' kextsock.cpp:353: implicit declaration of function `int __htonl(...)' Hmm. This should be non-fatal in any event, but which header does it include to get it's htons() and htonl() prototypes? netinet/in.h, arpa/inet.h, or sys/param.h? Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. This is almost completely bogus. I recently saw a PR of similar bogusness. As you might guess, this is a less than desirable situation. A #includes B and B #includes A is a very bad arrangement. However, unless both files are overhauled, that is what will have to happen. Hello? I've been overhauling arpa/inet.h (and netinet/in.h) for over six months. The new kernel endian functions complicated things much more. In the meantime, you need to find every occurence of either of those files being included, and make sure the other is included as well. netinet/in.h needs to come first. This is untrue. arpa/inet.h can appear before netinet/in.h or vice versa (remember to include sys/types.h before netinet/in.h, since netinet/in.h isn't a POSIX-2001 header yet). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
David W. Chapman Jr. [EMAIL PROTECTED] writes: Hmm. This should be non-fatal in any event, but which header does it include to get it's htons() and htonl() prototypes? netinet/in.h, arpa/inet.h, or sys/param.h? Yes. Recent changes to netinet/in.h have made it require the inclusion of arpa/inet.h. As well, arpa/inet.h must include netinet/in.h. IOW, each of these files must #include the other in order to work correctly. From reading all the posts, I believe the solution has been to manually modify the kde port to do this. Maybe not. I think missing prototypes might be fatal in C++. If this is the case, my new endian patch will fix this. Try compiling KDE after installing a world with the following patch applied: http://people.FreeBSD.org/~mike/patches/endian-ng3.diff I plan on committing this on Sunday. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: grp.h fix is incomplete
Garance A Drosihn [EMAIL PROTECTED] writes: At 9:25 PM +0300 3/7/02, Andrey A. Chernov wrote: grp.h fix is incomplete because 'u_int32_t' is not defined (but must be) for standalone grp.h. Please add some includes for u_int32_t definition too, probably sys/types.h Perhaps subconsciously I was trying to keep making software include sys/types.h before grp.h. :) I just committed a fix. As a minor side question, should we also have that defined as uint32_t instead of u_int32_t ? Yes, usually. I just grabbed the copy from sys/types.h, which wasn't correct. uint32_t is more correct, but requires pollution from another header, so I used the __uint32_t variant. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
I've been working from Gordon Tetlow's work on this, for the past few
weeks. I have managed to get most everyting up to network_pass3 in
/etc/rc. It's still very much in development, but it's quite usable and
I use it to boot my system on a daily basis.
I chose to go a slightly different route than Gordon, in that I have not
tried to make the scripts compatible with NetBSD (His scripts include
conditionals for NetBSD, mine don't). These are my reasons.
- IMO startup scripts should be system specific
- Converging startup scripts before the rest of the system is converted
will be a nightmare because there are too many differences.
Examples why:
- The -w switch is deprecated in FreeBSD, and NetBSD still
requires the -w switch in order to set a sysctl. This means
that we need a conditional in the script every time we set
a sysctl.
- We use different switches to startup the same daemon
- Who volunteers to test/coordinate/merge changes with the
NetBSD people?
- Each project is going to have scripts that the other project
won't use. This means someone has to invest the time and
effort to maintain scripts the project won't be using
- IMO all the conditionals are just going to obfuscate the
scripts and make them that much harder to debug
I have have followed Gordon's lead with his original patch and tried to
integrate the patch set into the base system. There's a knob in rc.conf
to use the new rc or the old one. In order to make it useable, even
while it's in development, I have organized the rc script so that when
it finishes processing the files in /etc/rc.d it continues the
current-style script where the last rc.d script left off. I've broken
the patch into 3 separate diffs to make it easier to see the changes.
Instructions:
http://home.pacbell.net/makonnen/rcng.tar.gz
unpack the tarball
cd /usr/src
patch {path to rc.d.diff}
patch {path to etc.diff}
patch {path to sbin.diff}
cd sbin/rcorder
make depend
make
make install
mergemaster -is # The -s switch is important
add rc_ng=YES to your /etc/rc.conf
I know everyone has their own idea for what the system should look like,
but I hope the work done already will help lighten the load. If you
choose not to base the final system on this I would still be willing to
contribute to whatever you decide to go with.
cheers,
mike makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
On Thu, 2002-02-28 at 09:02, Terry Lambert wrote: Thanks for the hard work, Mike! Thanks, nice to know someone appreciates it. Every one has their own ideas about how it _should_ be done, so I expected I'd get flamed for not pleasing everyone. OTOH it's been less than 24 hours since I posted it, maybe I should wait a couple more days :-) You could handle most of this using something like: rc.bsd: # Normalize difference between BSD's # # This is the FreeBSD version # SYSCTL_W=sysctl FOOARGS=-t -U # Normalize difference between BSD's # # This is the NetBSD version # SYSCTL_W=sysctl -w FOOARGS-u I understand what you're saying, but my problem is with the larger issue of making the startup scripts more complex (even though the reason for introducing a new rc system is to make them simpler) when the right thing to do, IMO, is to make the rest of the system more compatible so that the startup scripts can be simpler. Yes, but the person who does the work is always the ultimate arbiter of how it gets done. One of my professors was fond of reformulating Occam's Razoer as Anything that works is better than anything that doesn't. Ha ha! I like that one. I'll have to remember it the next time I'm thinking of all those unfinished projects I have sitting in the back of my mind. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
On Thu, 2002-02-28 at 09:23, David O'Brien wrote: On Thu, Feb 28, 2002 at 08:39:33AM -0800, Mike Makonnen wrote: I chose to go a slightly different route than Gordon, in that I have not tried to make the scripts compatible with NetBSD (His scripts include conditionals for NetBSD, mine don't). These are my reasons. The point you are missing is that we can work with the NetBSD guys to maybe change the NetBSD framework such that it works better for *both* systems. It is totally stupid to not share as much of the existing body of work with NetBSD. If you have ever had to administrate or use more than one Unix OS, you know how gratuitously different things are in them. Typically for no good reason. I don't think I articulated myself very well in my email. I am not against sharing code with NetBSD and I don't like gratuitous diffs any more than the next guy, but the differences in our scripts are because of gratuitous diffs elsewhere in the system. I think it's better to eliminate the differences elsewhere in the system. Then the scripts will naturally converge, with less need for conditionals. The 'sysctl -w' issue is a trivial example, but let me use it again. My argument is that it is better to have NetBSD support writing to sysctls without a '-w' switch, so that the same invocation works for both OS, than to maintain a mechanism, in the startup scripts, by which to work around the issue. Let's take another example. The REQUIREMENT line in a script cannot be made conditional. It requires a modification of rcorder(8) to do so. So, if one of NetBSD's services has a requirement that we don't have, it automatically means we need two separate scripts with different REQUIREMENT lines regardless of whether the rest of the script is identical. BTW, from a quick glance at the rcorder(8) source, modifying it to eliminate this problem is not going to be a trivial task. - Each project is going to have scripts that the other project won't use. This means someone has to invest the time and effort to maintain scripts the project won't be using I know we will not have 100% identical implementations. But people seem to want to use the NetBSD bits as reference but change things to how the should have been done. Now, that I've had a bit more time to think about it, I appreciate better the point you're making. I still think it's better to make the rest of the OS more compatible, but I can understand your point. What bothered me about it initially is that it seemed you wanted 100% compatibility and _all_ of it directed at making our startup process conform to NetBSD's. The reason I eschewed making the scripts NetBSD compatible is because once I saw how Gordon did it and I actually started converting the scripts I gained a better appreciation for the amount of work it entailed. It's going to be a tedious and long process probably, but I can see the merits now if the NetBSD people are willing to work with us. For example, I prefer our method of mounting local and then remote file systems, rather than having the sysadmin specify critical_filesystems in rc.conf ( I can already imagine the flood of emails to freebsd-questions: Help! My system won't boot... :-). Can I make a few suggestions: - Aim for at least a six month shake-down, with rc_ng=YES by default, in -Current before 5.0-Release. - A. Leave the current scripts as they are, for the moment. As new scripts get converted make them NetBSD compatible. Then work on making the initial scripts converge. This option will probably take some time. or B. Leave the current scripts as they are, for the moment. Get the scripts converted as quickly as possible. If possible make them NetBSD compatible from the start, but the overriding factor is getting the new system up and running in -Current so that people can start using it while the larger and slower task of converging the scripts goes on in parallel. Getting the rest of the rc system converted should only take a couple of weeks. - It may be useful to fix _some_ compatibility problems in the base system, even if just to reduce the complexity of a script. However, I have a suspicion we would just get bogged down in flame-fests between the two projects over who's implementation is better :( - I think on some things, the two projects may agree to disagree on, which means the majority of the code base will probably be 'identical', but there will be differences in things like, boot order, requirements, etc. I am of the opinion that it would be better to just get the system up and running to start with, and then work toward making them as identical as possible as we move forward. Never
-Current is stable enough for use again
FWIW, now that Peter has temporarily backed out his pmap-related changes, -current has stabilized again. Those who were having trouble with panics on boot (or within a few minutes after) with kernels built during the last day or two should definitely cvsup. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Today's panic on boot problem
I'm experiencing the same double panic on boot that PHK is now; are we the only ones, or is it just that nobody else has updated recently? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: I'm experiencing the same double panic on boot that PHK is now; are we the only ones, or is it just that nobody else has updated recently? If you are not using acpica, then you're probably using vm86 for pcibios calls. I've been told that I've broken bios.c.. You may like to try reverting this change: peter 2002/02/25 13:42:23 PST Modified files: sys/i386/i386bios.c sys/i386/include pmap.h Log: Tidy up some warnings Revision ChangesPath 1.47 +7 -6 src/sys/i386/i386/bios.c 1.74 +1 -1 src/sys/i386/include/pmap.h Cheers, -Peter I reverted that change, and the double panic still occured. :| FWIW, you're correct in that I'm not using the acpi module. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Mike Silbersack wrote: I reverted that change, and the double panic still occured. :| FWIW, you're correct in that I'm not using the acpi module. Mike Silby Silbersack Using ACPI doesn't help here either. Hmph. Can I get a kernel dump that early in the boot process? The dumpon manpage doesn't suggest a way as far as I can tell. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, David Wolfskill wrote: Date: Tue, 26 Feb 2002 19:46:59 + (GMT) From: Mike Silbersack [EMAIL PROTECTED] Using ACPI doesn't help here either. Hmph. Can I get a kernel dump that early in the boot process? The dumpon manpage doesn't suggest a way as far as I can tell. I was unable to get a dump, even though the panic dropped me into the debugger. Also, I only had the panic on my laptop -- the (SMP) build machine ran fine. Cheers, david (links to my resume at http://www.catwhisker.org/~david) Hm, sounds like UP got optimized out. Ok, I guess we wait... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: Hm, sounds like UP got optimized out. Gah! That would be a first. :( Well, until I can build a working kernel, I'll just assume that it's a feature. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, 26 Feb 2002, Peter Wemm wrote: FWIW, turning off PG_G see_ms to help. Change in pmap.c: #if !defined(SMP) || defined(ENABLE_PG_G) to: #if /*!defined(SMP) ||*/ defined(ENABLE_PG_G) and see how you go. This got me past atkbd0, but it is a very worrying sign. I now get a vnode related panic. :-( I've reread the changes about 50 times now and cannot for the life of me see why it works for SMP but not UP. I'm about ready to back it all out. Cheers, -Peter Disabling PG_G allows it to work here again as well. Given the problems we're experiencing, backing out the pmap changes of the last two days seems like a good idea. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Wed, 27 Feb 2002, Mike Silbersack wrote: Disabling PG_G allows it to work here again as well. Given the problems we're experiencing, backing out the pmap changes of the last two days seems like a good idea. Mike Silby Silbersack Well, I sorta take that back. The box has been up for ~5 minutes now, and the buildworld I started hasn't paniced it yet. I guess this is workable. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
On Mon, 2002-02-25 at 20:59, M. Warner Losh wrote: I've fixed a few of the low hanging fruit, but I don't know how to get rid of warnings like: const char *foo = blah; char *baz = foo; when I know they are safe. Correct me if I'm wrong, but isn't the correct declaration: const char foo[] = blah; char baz[] = foo; cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Doug Barton [EMAIL PROTECTED] writes: A couple months ago an improvement was added to the color support of ls to use a wider variety of colors, indicated by alphabet characters instead of numbers. While I think this is a good change, it included a warning when users have the old style numeric flags in their LSCOLORS variable. I think this is a mistake, and needlessly places another barrier for users coming into -current. Since the support for the old style color flags is practically free, I'd like to suggest that rather than warning the user, we simply continue to support the old flags, and indicate that they are deprecated in the man page. Deprecated features should generate warnings. See the Committers Guide (8.3) for details. The change to the manual is correct though. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Doug Barton [EMAIL PROTECTED] writes: Mike Barcroft wrote: Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. I don't have any objections to making this a supported legacy mode, but I think deprecated features (things we *want* to go away) should produce warnings. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: ACPI CA updated
I've finally updated the ACPI CA codebase with Intel's 20020214 drop (yes, I tagged it 0217, my bad). This is the first drop that Intel haven't asked me not to commit since the 20011120 version, so there are a large number of changes and bugfixes. See Intel's logs at http://developer.intel.com/technology/iapc/acpi for more details. There aren't many changes in the FreeBSD-specific code, this is just catching up with major improvements in the interpreter. As usual, please report any problems or success to the list. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
Terry Lambert [EMAIL PROTECTED] writes: Other people's code has dropped by the wayside completely, and been lost; the SACK/TSACK work Luigi did never got integrated and accepted by the project, and LRP code that Peter Druschel and Gaurav Banga did at Rice University, which was originally done against FreeBSD 2.2. For that matter, we've also lost out on integration of the IO-Lite code, also from Rice (both were a result of the ScalaServer project). Likewise, the CMU work on TCP Rate Halving (admittedly, it's based on NetBSD 1.3.2, but that's not that significantly different from FreeBSD to matter), as well as their FACK/SACK implementation. I'm getting sick of reading this. Terry, if you want this code integrated into FreeBSD, here's what you do: 1) Find yourself a mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current sources, 4) Have them reviewed, 5) Commit them. If you aren't interested in doing this, you are the sole person to be blamed for them not being integrated into FreeBSD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Forking FreeBSD: CVS vs. P4
Terry Lambert [EMAIL PROTECTED] writes: Mike Barcroft wrote: I'm getting sick of reading this. Terry, if you want this code integrated into FreeBSD, here's what you do: 1) Find yourself a mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current sources, 4) Have them reviewed, 5) Commit them. If you aren't interested in doing this, you are the sole person to be blamed for them not being integrated into FreeBSD. And I'm getting sick of being dragged down into details in what should be a meta-discussion, thus effectively glossing over the major point in order to pick on one or two objectionable paragraphs out of an entire posting. [Discussion related to the root of the thread, rather than my message, removed.] I see you are not interested in doing this. -CURRENT READERS TAKE NOTE: No longer can Terry blame CVS, P4, Gnats, our two seperate branches of development, FreeBSD developers, or the color of the sky; Terry can be attributed to be the sole reason why these outside projects have never been integrated into FreeBSD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Newbie ddb question
I've been poking around in ddb in an attempt to work on some forkbomb/low memory problems, and I've found it extremely useful. There's one thing I can't figure out how to do that would be useful, though. Say that I have a process of interest tsleeping. Is there some way for me to get a backtrace of that process at the time it entered tsleep? In the case I'm creating, many processes are tsleeping on vmwait. As there are multiple places where such a wait can occur, I'd really like to see which codepaths are causing processes to enter that state. The trace command doesn't seem to have the necessary functionality to do this, so I was thinking that I might be able to simulate such an effect by putting a null pointer reference right before such calls, thereby creating a panic. Is this the best way to go, or is there some easier way to accomplish a similar effect? Thanks, Mike Silby' Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Newbie ddb question
On Thu, 14 Feb 2002, Bruce Evans wrote: On Thu, 14 Feb 2002, Mike Silbersack wrote: I've been poking around in ddb in an attempt to work on some forkbomb/low memory problems, and I've found it extremely useful. There's one thing I can't figure out how to do that would be useful, though. Say that I have a process of interest tsleeping. Is there some way for me to get a backtrace of that process at the time it entered tsleep? In the case I'm Try t pid. Bruce Ah, I see now. That never got MFC'd to -stable. I'll see if it's easily MFCable, or just move my testing over to -current. Thanks, Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non 386 testers REALLY NEEDED
Wilko Bulte [EMAIL PROTECTED] writes: C'mon guys: it is not so long ago (days..) that the Alpha started buildworlding -current again. Alpha builds tend to take much longer (on most people's hardware that is) so a bit of patience would be nice. FWIW: I'm trying to get 2 of my Alphas to go to -current again. Running most things compiled with the new binutils on Alpha causes segfaults. Be very careful not to install anything compiled with it. To test KSE on Alpha I recommend locally backing out the new binutils until David or another developer resolves the issues with it. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Peter Wemm [EMAIL PROTECTED] writes: 2: We need to get a *basic* compiler up and running first. Give David a break, ok? There are far bigger problems to deal with first before futzing around on obscure languages that we have no critical need for in the base system. We ***NEED*** the ability to compile basic C code for the sparc64, ia64 and x86-64 platforms. Until that is dealt with, the rest is a luxury. Yes, absolutely. Every minute David spends replying to these idiotic suggestions wastes valuable project time. How many FreeBSD users need to compile Java to machine code? 2, 3, 4 people? How hard is it to use `pkg_add -r' and rearrange your PATH to make a stock GCC work? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Nat Lanza [EMAIL PROTECTED] writes: You know, people might be less persistent about these idiotic suggestions if they got treated with some civility and respect. From what I read, the participants in this thread were very civil and respectful. I don't think the original poster had given his suggestion much thought before bringing it up though. :( It's a lot more meaningful and useful to receive an explanation, even a brief one, about why your suggestion isn't good than it is to receive personal abuse. If you simply abuse someone, they're just going to think you're a jerk, not that their ideas are bad. I completely agree. I found David's explanations quite helpful in determining the legitimacy of the original suggestion. More flies with honey, and all that. I've noticed a lot of nastiness in this thread, and it's really pretty disappointing. Yes, you're all busy people. Yes, this is a volunteer project. Yes, people are never satisfied with what others do for them for free. That sucks, sure. But it doesn't make it okay to treat people like crap for daring to disagree with you. I didn't notice much nastiness, but I guess I wasn't really looking for it. I did notice that some people were wasting a developer's time when the project as a whole needs it much more. I'm talking, ofcourse, about the imminent GCC upgrade that David is working on. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Andrew Cowan wrote: However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. I was on the verge of doing so the other day. Basically, I wanted to have standard configuration data describing the network, services and service configuration stored in XML and use XSLT to produce which-ever config files you need. You then introduce some inheritance and allow configuration to be overridden for particular hosts, subnets, networks, and/or platforms, and you have a powerful site-wide configuration management tool. You get all the usual benefits from using XML as well; data source, processing and output independence, so the configuration data could be use to automatically generate HTML for helpdesk pages, could be sourced from existing a variety of new or pre-existing data repositories (LDAP, CVS, file system, etc.) and could be processed and edited using a number of standard tools. If only I had not run out of time write it, I'd be happily using this today. Mike. -- Mike Gratton [EMAIL PROTECTED] Every motive escalate. Blatant self-promotion: http://web.vee.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_ssh world breakage (was: Re: cvs commit: src/lib/libpam Makefile.inc)
David O'Brien [EMAIL PROTECTED] writes: Not to mention there is ZERO way this code will pass WARNS=4 for GCC 3. Please Committers, do not try to WARNS code right now -- there just is no use. It will only get in the way later. Well, of course feel free to make the code changes, but PLEASE do not commit any stronger WARNS levels to Makefiles. Alternatively, developers working on WARNS could use a newer GCC from the ports collection. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Junior Annoying Hacker Task
[Context lost to top posting.] Andrew Cowan [EMAIL PROTECTED] types: How about editing the rc.conf file from the proposed virc program, that would then re-generate the rc.conf file upon saving. Of course the virc would store the underlying configuration in an xml config file.. That should make Kutulu very happy :) I think it should be called viconf, as it should work on rc.conf, make.conf, periodic.conf, and any other .conf files we want. I would like to remind viewers that I am just kidding I didn't take you seriously, except about the name. However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. It would allow gui tools to be easily designed for system administration. I don't see how it would make it any easier than using flat text files, unless you're planning on providing a DTD and using generic XML gui editors. Putting data in XML doesn't automatically imbue it with anything, except the ability to use generic XML tools on it. Of course, given line-seperated records with a unique field separator, you can use generic tools on those just as well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LINT Broken
With up-to-date sources: sh /work/src/sys/conf/newvers.sh LINT -DGPROF -DGPROF4 -DGUPROF cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/work/src/sys -I/work/src/sys/dev -I/work/src/sys/contrib/dev/acpica -I/work/src/sys/contrib/ipfilter -I/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue vers.c linking kernel uhci.o: In function `uhci_idone': uhci.o(.text+0x1330): undefined reference to `uhci_dump_ii' uhci.o: In function `uhci_device_isoc_done': uhci.o(.text+0x2fab): undefined reference to `uhci_dump_ii' *** Error code 1 Stop in /usr/obj/work/src/sys/LINT. *** Error code 1 Stop in /work/src. *** Error code 1 Stop in /work/src. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Terry Lambert [EMAIL PROTECTED] types: I guess NIH beats an idea to death, even if the original implementation bears no resemblence to the current one. The problem with the registry is not that it's a single place that tries to control everything. The problem with the registry is that you have to have a large chunk of the system functioning in order to fix things in it should it break - which, from what I've seen, happens all to frequently. Compare this to unix, where all you need is the kernel, init, sh and ed - and sufficiently clever people may be able to do it without init. I offer AIX as an example. IBM decided that all those silly flat text files in Unix was a bad idea and replaced them with object database. They didn't put everything in one big file like Windows does, but grouped them logically, meaning the grouping was unrelated to the flat text files unix admins used to know. Of course, each different db used a different command, with a different syntax, to edit the db. I guess if you're going to make old knowledge useless, you might as well be thorough about it. What this meant in practical terms was that fixing the system required all the db mechanisms to be working, plus either the man pages or menu-driven admin tool to be working in order to fix a broken system. And that was one of the better features of AIX. Juha Saarinen [EMAIL PROTECTED] types: On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: Then again, the registry is the epitome of all that's counter-intuitive, awkward and generally oh-why-does-it-have-to-be-like-this. Maybe it should be ported to FreeBSD? ;- I haven't followed the thread, so apologies if this is repeated. I think having menu-driven front end for editing *.conf files - right now, that would be rc, make, pccard and periodic - isn't such a bad idea. Nothing about the current behavior needs to change. It's no worse than letting people use the sysinstall disk management subsystem rather than fdisk and disklabel. Ideally, it would read all of /etc/defaults/*.conf for a description of each such file. When you chose to edit that file, it would read the contents for the list of variables and what they do - in the comments - along with the default values, then get the current values from the appropriate file in /etc. That means the tool doesn't get out of sync with the files - except for maybe make.conf. It would require reworking the comments in the files in /etc/defaults, and a little more discipline in editing them, but that's not necessarily a bad thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
[-hackers removed from CC. One list is enough.] Alp Atici [EMAIL PROTECTED] writes: Is gcc 3.x going to be the default compiler starting from FBSD 5.x series? Is the development on current branch compiled using gcc 3.0 (or up)? Yes. Not yet. Is 5.x series going to be based on a preemptible kernel? That's the plan. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
Dan Nelson [EMAIL PROTECTED] writes:
In the last episode (Jan 19), Terry Lambert said:
Alp Atici wrote:
Is gcc 3.x going to be the default compiler starting from FBSD 5.x
series? Is the development on current branch compiled using gcc 3.0
(or up)?
I think that the cut over will happen after the compiler
no longer core dumps on:
main()
{
int i;
i = foo();
switch( i) {
default:
printf( hello, stupid compiler!\n);
break;
}
}
int
foo()
{
return( 6);
}
Doesn't core on me (gcc30+bounds-checking port, FreeBSD-current). In
fact, I've got USE_GCC30 in my make.conf and build all my ports with it
(at least the ports that aren't broken and hardcode cc or gcc).
Interesting. The sparc64 toolchain suffers from this problem, so a
number of files on the sparc64 p4 branch have custom versions.
Anyway, I'm told this problem has been fixed in 3.1, which is the
planned version of GCC for 5.0-RELEASE.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: boot floppy problems...
oh, well. They say something along the lines of Disk error: lba is 0x9 (should be 0x10) or similar. then it trys to boot the kernel twice using the loader, but fails with the path 0:fd(0,a)/kernel i tried it in vmware with the same results comming right from the image. mike On Thu, 17 Jan 2002, John Baldwin wrote: On 17-Jan-02 Mike Brancato wrote: Just leting you guys know that the Jan 15th and Jan 16th boot floppies aren't working. the Jan 13th snaps are though. How do they not work? We can't fix anything if you don't tell us what is wrong. :) mike -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use 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: boot floppy problems...
no problem. keep up the good work. mike On Thu, 17 Jan 2002, Ian Dowse wrote: In message Pine.LNX.4.21.0201170805060.3093-10@dosmonos, Mike Brancato wr ites: oh, well. They say something along the lines of Disk error: lba is 0x9 (should be 0x10) or similar. then it trys to boot the kernel twice using the loader, but fails with the path 0:fd(0,a)/kernel Hmm, the error is actually Disk error 0x9 (lba=0x10). I think this is my fault. Error 9 is data boundary error (attempted DMA across 64K boundary or 80h sectors), so by changing the buffers to being static in revision 1.35 of boot2.c, I broke the guarantee that single transfers don't cross a 64k boundary, which is important for floppies :-( I'll fix this shortly. Thanks for pointing out the problem! Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot floppy problems...
seems to work in vmware now. maybe i'll cvsup my source and rebuild my machine tonight. fun. thanks. mike On Thu, 17 Jan 2002, Ian Dowse wrote: In message Pine.LNX.4.21.0201171724390.5037-10@dosmonos, Mike Brancato wr ites: no problem. keep up the good work. mike Ok, it's fixed now. If you'd like to try it, there's an updated version of the kern.flp from today's -CURRENT snapshot at: http://www.maths.tcd.ie/~iedowse/FreeBSD/kern.flp Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
boot floppy problems...
Just leting you guys know that the Jan 15th and Jan 16th boot floppies aren't working. the Jan 13th snaps are though. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new module-references compile error
On Sat, 12 Jan 2002 13:22:47 +0100 (MET) Michael Class [EMAIL PROTECTED] wrote: pc-micha:/sys/i386/compile/MCSMP2# make linking kernel.debug linprocfs.o: In function `linprocfs_donetdev': /sys/i386/compile/MCSMP2/../../../compat/linprocfs/linprocfs.c(.text+0xfe9): undefined reference to `linux_ifname' *** Error code 1 A few days ago changes were made to sys/compat/linux/linux_ioctl.c (rev. 1.79, I believe) that removed linux_ifname(). Just checkout rev. 1.78 and use that instead. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new module-references compile error
On Mon, 14 Jan 2002 11:25:47 +0600 (NOVT) [EMAIL PROTECTED] (Nickolay Dudorov) wrote: And now linux_ioctl.c has rev. 1.81 and you can not simply revert it to the rev 1.78 or 1.77. The commits after 1.79 touch a different part of the file. Just reverse diff 1.79 and patch it onto 1.81. Everything except the ident string should succeed. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LINT broken
LINT appears to be broken: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/work/src/sys -I/work/src/sys/dev -I/work/src/sys/contrib/dev/acpica -I/work/src/sys/contrib/ipfilter -I/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue /work/src/sys/dev/usb/uhci.c /work/src/sys/dev/usb/uhci.c: In function `uhci_dump_all': /work/src/sys/dev/usb/uhci.c:694: structure has no member named `hlink' /work/src/sys/dev/usb/uhci.c: At top level: /work/src/sys/dev/usb/uhci.c:1270: warning: `uhci_reset' defined but not used /work/src/sys/dev/usb/uhci.c:261: warning: `uhci_dump_ii' used but never defined *** Error code 1 Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: module build process changed
I've recently committed a series of changes which affect the way modules are built. Since I can't test *every* module, please let me know immediately if you run into problems with modules refusing to load due to undefined symbols, or not working quite right. I've tried hard to make sure it's all correct, but bugs and errors are inevitable. Some overview of what this achieves: Previously, there have been two symbol namespaces in the kernel; the global symbols namespace and the per-source-file namespace. To build a module with more than one source file, one typically had to expose some symbols to the global namespace, risking accidental collisions with other modules. The common workaround for this has been to prefix all exported symbols with a few characters identifying the module, but as we accumulate more modules, this mechanism is becoming less reliable. In order to deal with this problem, I have changed the module build process so that symbols global to the module are converted to local symbols when the module is linked into the .kld/,ko file. In order to allow modules that intentionally export symbols to continue to do so, a new module makefile variable 'EXPORT_SYMS' has been implemented. This variable may take three values; YES will revert to the traditional behaviour of exporting all globals. It should typically only be used when converting a module from 4.x, or to quickly verify that a problem is due to a failure to export a symbol. A list of symbol names may be given, and these symbols will be exported. And thirdly, the name of a file may be given, and this file will be read for the list of symbols to export. Note that it is not an error to list a symbol not found in the module object. This allows modules to be built with different options without requiring different export lists. Looking to the near future, this technique will be extended to the building of monolithic kernels as well. The .kld files generated during a module build can be linked with a monolithic kernel, and thus much of the duplicate building of kernel source can be eliminated. Once this conversion is complete, the per-module namespace will behave consistently within the kernel as well. Questions and comments welcome. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: module build process changed
In the book Writing Linux DEvice Drivers, there is a neat bit on how Linux does this. Effectively, they export all symbols within the module load if there is no explicit symbol table export call, and they export only the symbols that are requested, if there is. I considered this approach, but couldn't work out a tidy way of making it work for the case where the module is statically compiled into the kernel. Effectively, you'd have to parse the linker set out of the .kld file, then feed it to objcopy to localise the symbols before linking. There's no reason that, presuming a mechanism like this was devised, we couldn't dispense with the EXPORT_SYMS declaration and generate the list automatically, of course. I'd be happier with something like __attribute__((__export__)) on the declaration, of course. I'm also not fond of the default to export all symbols approach, but that's just a detail. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: conf/31358: Updated patch for -CURRENT
On Tue, 8 Jan 2002 11:02:06 +0100
Thomas Quinot [EMAIL PROTECTED] wrote:
[snip]
+ # Handle absent nfs client support
+ if sysctl vfs.nfs /dev/null 21; then
+ nfsclient_in_kernel=1
+ else
+ nfsclient_in_kernel=0
+ fi
+
This should be handled inside the case statement for ${nfs_client_enable}, as you want
to load the nfsclient kld only if the nfs client is enabled.
case ${nfs_client_enable} in
[Yy][Ee][Ss])
+ kldload nfsclient nfsclient_in_kernel=1
+
+ case $nfsclient_in_kernel in
+ 1)
+ ;;
+ *)
+ echo 'Warning: NFS client kernel module failed to load'
+ nfs_client_enable=NO
+ ;;
+ esac
+ ;;
+ esac
+
+ case ${nfs_client_enable} in
+ [Yy][Ee][Ss])
if [ -n ${nfs_access_cache} ]; then
echo -n NFS access cache time=${nfs_access_cache}
sysctl
vfs.nfs.access_cache_timeout=${nfs_access_cache} /dev/null
@@ -732,6 +754,27 @@
echo -n ' rpc.lockd'; rpc.lockd
;;
esac
You should clean this up so there is only *one* 'case ${nfs_client_enable}'.
Look at the implementation of case ${nfs_server_enable}, earlier in rc.network for an
example of how it should be done.
Cheers,
mike makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: undefined reference to `pfs_statfs'
You should read UPDATING. PROCFS now requires PSEUDOFS. mike makonnen On Tue, 8 Jan 2002 23:48:44 - ADRIAN.BROWNE [EMAIL PROTECTED] wrote: Anyone got any ideas kern.version: FreeBSD 5.0-20020102-CURRENT #0: Wed Jan 2 12:00:48 GMT 2002 make failed on /usr/src/sys/i386/compile/WARSPITE/../../../fs/procfs/procfs.c(.data+0x6c): undefined reference to `pfs_root' /usr/src/sys/i386/compile/WARSPITE/../../../fs/procfs/procfs.c(.data+0x74): undefined reference to `pfs_statfs' *** Error code 1 source updated by cvs on 8-1-2002 still failed :( [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: ftpd STOR and STOU work the same ?
On 04-Jan-2002 Riccardo Torrini wrote: | On 29-Dec-2001 (16:49:06/GMT) Riccardo Torrini wrote: | | I noticed a strange behaviour, sending a file twice create | version even if sunique is off, on all versions I can test. | | This includes: | - FreeBSD 5.0-CURRENT #0: Sun Dec 9 08:37:55 CET 2001 | - FreeBSD 4.4-STABLE #6: Fri Oct 12 21:44:36 CEST 2001 | - FreeBSD 4.5-PRERELEASE #0: Fri Dec 28 18:47:34 CET 2001 | all updated with cvsup and a fresh installed 4.2 from cdrom: | - FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000 | | Also tested on other versions on the same range (4.2 - 5.0) | and noticed that happens only with anonimous (ftp) user but | _not_ with regular users. Hope this can help... | | Tryed with /etc/inetd.conf standard config where ftpd runs | with -l and with my own custom -llSA, the same. | Tryed from local (ftp localhost) and from remote machine, even | with another OS (hpux and openbsd). The same. I'm really sad. | I'm (pretty) sure isn't a 'pilot-error'. Please comfirm this... | | Thanks again. | This is intentional. If you are running an anonymous file drop, you don't want guest users to be able to overwrite the files of others. If you need to upload, and overwrite a file, you might try setting up a restricted user for this purpose, that only has write access to a single directory. Mike -- Mike Heffner mheffner@[acm.]vt.edu Fredericksburg, VA [EMAIL PROTECTED] msg33416/pgp0.pgp Description: PGP signature
RE: ftpd STOR and STOU work the same ?
On 05-Jan-2002 Riccardo Torrini wrote:
| On 05-Jan-2002 (19:47:53/GMT) Mike Heffner wrote:
|
| I noticed a strange behaviour, sending a file twice create
| version even if sunique is off, on all versions I can test.
|
| This is intentional...
|
| This is black magic. I hate it. I hope this would be (soon)
| documented _OR_ make configurable.
| ...or at least tell me where I can un-patch myself ;)
Sure, it can be made configurable. Unfortunately, our current ftpd doesn't
support a config file like lukeftpd, or others, so it would have to be
implemented as a new argument.
The patch is simple, find the following code in ftpd.c, and just remove
the 'guest' in the first conditional.
void
store(name, mode, unique)
char *name, *mode;
int unique;
{
FILE *fout, *din;
struct stat st;
int (*closefunc) __P((FILE *));
if ((unique || guest) stat(name, st) == 0
(name = gunique(name)) == NULL) {
LOGCMD(*mode == 'w' ? put : append, name);
return;
}
...
|
|
| If you need to upload, and overwrite a file, you might try
| setting up a restricted user for this purpose, that only
| has write access to a single directory.
|
| Why? Assume I have a very restricted /incoming dir (111) and
| one or two levels or restricted dir under that (.../foo/bar/)
| also with mode=111, and assume that a file named write-me is
| placed in that dir owned by anonimous, mode +w.
| Nothing can imagine files and dir if is unable to list them,
| so only authorized users or automatic robots can read/write
| under that deep path.
True, as long as the filename is not easily guessable, but it's still
security through obsecurity. ;)
|
| Assume also that I need 2^n (a very large number) different
| users to write on my ftp a sort of report, all the times with
| the same name. I can't delete/put because dir is not writable.
I don't quite follow this, do you have some other method involved to
move/copy the files to another location before the next user logs in and
overwrites the file?
|
| Do you think this is a 'too-crazy' request?
No, feel free to submit a patch.
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
Fredericksburg, VA [EMAIL PROTECTED]
msg33423/pgp0.pgp
Description: PGP signature
Re: vnode_if.pl broken
On Fri, 4 Jan 2002, Bruce Evans wrote: Kernel builds now fail with the following error message: Global symbol $FreeBSD requires explicit package name at ./@/kern/vnode_if.pl line 82. Use of $* is deprecated at ./@/kern/vnode_if.pl line 82. Global symbol $FreeBSD requires explicit package name at ./@/kern/vnode_if.pl line 98. Execution of ./@/kern/vnode_if.pl aborted due to compilation errors. Bruce Crap. Ok, working on it. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVSup vs inttypes.h,v
Julian Elischer [EMAIL PROTECTED] writes: Well it's a pitty whoever moved it didn't grep for it.. my builds fail because of it. I did indeed grep for occurences of it and fixed them. The only remaining instance appears in sys/dev/bktr/bktr_core.c which is in a `#if defined(__NetBSD__) || defined(__OpenBSD__)' section. If you are interested in the types that used to be defined there, they are now in sys/stdint.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: anyone seen this? Makes system unbooable.
I upgraded by cvs on saturday night, Sunday I didn't use it. Monday I tried to boot it. but the loader says: ASSERT mumble and the system reboots I'd LOVE to know wha the assert is but really My opical neurons take at least 20mSecs to fire and by the time I've found the Asssert line I'm already running on afterimage. How about adding a sleep after the Assert write so that it can actually be read? Is it printing ASSERT blah, or Assertion failed:? The string ASSERT doesn't exist anywhere in the loader or libstand. If you want to add a pause after an assertion failure (not a bad idea really), do it in src/lib/libstand/assert.c. In the meanwhile does anyone know what the problem might be.. I'm recvsuping (I had to boot off a cdrom) and will recompile the bootblocks, but some idea of the problem might be nice.. You *are* aware that you can boot loader.old by hitting a key while the spinner is paused, before the loader starts, right? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet
On 29-Dec-2001 John Hay wrote: | This patch works just fine here, thanks. | | Any chance of getting it as part of lukem distribution or ours? | Luke has incorporated it into NetBSD's ftp, and it will be included with the next import of lukemftp. Mike -- Mike Heffner mheffner@[acm.]vt.edu Fredericksburg, VA [EMAIL PROTECTED] msg33304/pgp0.pgp Description: PGP signature
Re: 21 in /bin/sh
KT Sin [EMAIL PROTECTED] writes: Just ran make world this morning and 21 fd redirection stopped working for /bin/sh. $ ls /bad/file /dev/null 21 ls: /bad/file: No such file or directory 21 is used extensively in the /etc/rc* bootup scripts. Now, the bootup screen is cluttered with unwanted messages. Any idea? AFAIK, this was fixed. Check the commit logs for sh(1). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New mail dumps core on current
On 19-Dec-2001 Manfred Antar wrote: | mail dumps core on current with latest /usr/src/usr.bin/mail updates: | Argh, I forgot braces around a 'for' loop. This has been fixed by Andrey in rev. 1.12 of send.c. Mike -- Mike Heffner mheffner@[acm.]vt.edu Blacksburg, VA [EMAIL PROTECTED] msg33139/pgp0.pgp Description: PGP signature
subscribe freebsd-current
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current doesnt see ps2 port with acpi enabled on intel vc820
Hi all Glad to hear that it worked for you. Just wondering..is your affected motherboard using AMI for BIOS? Mine is AMI too. I'll try to submit a PR. Hopefully the fix will be accepted. A PR that hardwires IRQ 12 probably won't be accepted. Can you look around the ACPI tables and try to see where the driver should be intuiting the IRQ from? In particular, have a look at the atkbdc device and see if it isn't being given two interrupts... kt On Sun, Dec 16, 2001 at 10:25:52AM -0500, Brian K. White wrote: - Original Message - From: KT Sin [EMAIL PROTECTED] To: Jon Christopherson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 15, 2001 10:24 PM Subject: Re: current doesnt see ps2 port with acpi enabled on intel vc820 I have just compiled and installed -current from this morning 7AMPST, and have noticed that when acpi is enabled in loader.conf the O S does not see the ps2 mouse port. When I turn off ACPI the mouse port shows up fine. Other than not seeing the ps2 port when in ACPI enabled mode, the OS works without a hitch on my motherboard. Any ideas? IF thi s is a known problem please let me know, as I have been off this list for a month or so. I'm seeing the same problem on my MSI bookpc. For some reasons, the psm device will fail to get an IRQ when ACPI is enabled. Can you try the attached patch and see if it helps? Hey I had the same problem but I assumed it was because I was slightly overclocking an amd k6-2 500 to 550 on a cheap old e-machine via-based motherboard. I applied your patch and no w my mouse works. thanks! blather although, partially in response to the mouse problem, I never use my kvm switch anymore anyways, just vnc on the rare occasion I feel like playing with x on this box. /blather Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI causes immediate reboot [Omnibook 6100] ?
You can define ACPI_DEBUG in the environment before building the kernel,
or when manually building the module, or in /etc/make.conf.
I've stumbled on the ACPI_DEBUG issue in the module load as well.
The ACPI_DEBUG definition only propogates to the opt_acpi.h file
in the base kernel. The acpi module build doesn't seem to carry
forward the ACPI_DEBUG flag. As a workaround, I just wack the define
into the opt_acpi.h file in the modules tree after running config
on a clean tree.
Hi,
I finally got around to hook up a serial console and capture the error
message. This is with ACPI_DEBUG enabled in the kernel config, but
ACPI is still loaded as a module, not configured statically.
acpi0: PTLTD EBRSDT on motherboard
ACPI-0294: *** Error: Method execution failed, AE_NOT_EXIST
What surprises me is that the debug.acpi.* settings don't seem to take
effect. Would I need to configure ACPI statically for them to work,
or is this problem just too early in the boot sequence?
And what can I try next?
--
Regards,
Georg.
snipserial console captured during bootsnip
OK show
LINES=24
acpi_load=YES
bootfile=kernel
console=comconsole
currdev=disk1s2a:
debug.acpi.disable=all
debug.acpi.layer=ACPI_HARDWARE
hint.acpi.0.oem=PTLTD
hint.acpi.0.revision=1
hint.acpi.0.rsdt=0x3ff6830a
hint.adv.0.at=isa
hint.aha.0.at=isa
hint.aic.0.at=isa
hint.apm.0.at=nexus
hint.ata.0.at=isa
hint.ata.0.irq=14
hint.ata.0.port=0x1F0
hint.ata.1.at=isa
hint.ata.1.irq=15
hint.ata.1.port=0x170
hint.atkbd.0.at=atkbdc
hint.atkbd.0.flags=0x1
hint.atkbd.0.irq=1
hint.atkbdc.0.at=isa
hint.atkbdc.0.port=0x060
hint.bt.0.at=isa
hint.cs.0.at=isa
hint.cs.0.port=0x300
hint.ed.0.at=isa
hint.ed.0.irq=10
hint.ed.0.maddr=0xd8000
hint.ed.0.port=0x280
hint.fd.0.at=fdc0
hint.fd.0.drive=0
hint.fd.1.at=fdc0
hint.fd.1.drive=1
hint.fdc.0.at=isa
hint.fdc.0.drq=2
hint.fdc.0.irq=6
hint.fdc.0.port=0x3F0
hint.fe.0.at=isa
hint.fe.0.port=0x300
hint.ie.0.at=isa
hint.ie.0.irq=10
hint.ie.0.maddr=0xd
hint.ie.0.port=0x300
hint.le.0.at=isa
hint.le.0.irq=5
hint.le.0.maddr=0xd
hint.le.0.port=0x300
hint.lnc.0.at=isa
hint.lnc.0.drq=0
hint.lnc.0.irq=10
hint.lnc.0.port=0x280
hint.npx.0.at=nexus
hint.npx.0.irq=13
hint.npx.0.port=0x0F0
hint.pcic.0.at=isa
hint.pcic.0.irq=10
hint.pcic.0.maddr=0xd
hint.pcic.0.port=0x3e0
hint.pcic.1.at=isa
hint.pcic.1.disabled=1
hint.pcic.1.irq=11
hint.pcic.1.maddr=0xd4000
hint.pcic.1.port=0x3e2
hint.pmtimer.0.at=isa
hint.ppc.0.at=isa
hint.ppc.0.irq=7
hint.psm.0.at=atkbdc
hint.psm.0.irq=12
hint.sc.0.at=isa
hint.sc.0.flags=0x100
hint.sio.0.at=isa
hint.sio.0.flags=0x10
hint.sio.0.irq=4
hint.sio.0.port=0x3F8
hint.sio.1.at=isa
hint.sio.1.irq=3
hint.sio.1.port=0x2F8
hint.sio.2.at=isa
hint.sio.2.disabled=1
hint.sio.2.irq=5
hint.sio.2.port=0x3E8
hint.sio.3.at=isa
hint.sio.3.disabled=1
hint.sio.3.irq=9
hint.sio.3.port=0x2E8
hint.sn.0.at=isa
hint.sn.0.irq=10
hint.sn.0.port=0x300
hint.vga.0.at=isa
hint.vt.0.at=isa
interpret=OK
kernel=kernel
kernel_options=
kernelname=/boot/kernel/kernel
loaddev=disk1s2a:
module_path=/boot/kernel;/boot/kernel;/boot/modules;/modules
prompt=${interpret}
OK boot
/boot/kernel/acpi.ko text=0x34d9c data=0x1090+0xbf8 syms=[0x4+0x4c80]
Copyright (c) 1992-2001 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.0-CURRENT #39: Sun Dec 16 22:25:29 CET 2001
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/HUNTER
Preloaded elf kernel /boot/kernel/kernel at 0xc0446000.
Preloaded elf module /boot/kernel/snd_maestro3.ko at 0xc04460a8.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc044615c.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0446208.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 1129576481 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (1129.58-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x6b1 Stepping = 1
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CM
OV
,PAT,PSE36,MMX,FXSR,SSE
real memory = 1073086464 (1047936K bytes)
avail memory = 1040580608 (1016192K bytes)
Pentium Pro MTRR support enabled
Using $PIR table, 14 entries at 0xc00fdee0
apm: Other PM system enabled.
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: PTLTD EBRSDT on motherboard
ACPI-0294: *** Error: Method execution failed, AE_NOT_EXIST
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Michael Petry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
... every activity meets with opposition, everyone who acts
Re: Buildworld broken on _FBSDID in xinstall.c ??
Michel Oosterhof [EMAIL PROTECTED] writes: I might be doing something wrong here, this is my first try at -CURRENT. Anyway, buildworld fails right at the start after yacc: It looks like Mark Murray broke xinstall.c in revision 1.45 by adding __FBSDID() to a build tool. FreeBSD localisms should not be used in build tools. Perhaps he would be so kind as to back out the offending code. Any suggestions? I would recommend removing the __FBSD() line locally until this has been resolved. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet
On 13-Dec-2001 Mike Heffner wrote: | mikeh 2001/12/13 15:46:45 PST | | Modified files: | usr.bin/ftp Makefile | Removed files: | usr.bin/ftp cmds.c cmdtab.c complete.c domacro.c | extern.h fetch.c ftp.1 ftp.c ftp_var.h | main.c pathnames.h ruserpass.c util.c | Log: | Connect lukemftp to the build as the default ftp client. Lukemftp | supports most of the previous features of FreeBSD ftp, but has been | better maintained and includes new features. Short summary of differences: New features: *) More automation methods *) Better standards compliance *) Transfer rate throttling (binary mode only currently) *) Customizable commandline prompt Differences/Losses: *) FTP_PASSIVE_MODE vs. FTP_MODE *) -4/-6 for forcing IPV4/IPV6 Mike -- Mike Heffner mheffner@[acm.]vt.edu Blacksburg, VA [EMAIL PROTECTED] msg33025/pgp0.pgp Description: PGP signature
Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet
On 14-Dec-2001 Mike Heffner wrote: | | Differences/Losses: | | *) FTP_PASSIVE_MODE vs. FTP_MODE s/FTP_MODE/FTPMODE As a followup clarification, ftp(1) will attempt to use passive mode by default, and fall back to active mode. To achieve the old default behavior (active mode) set FTPMODE=active. Mike -- Mike Heffner mheffner@[acm.]vt.edu Blacksburg, VA [EMAIL PROTECTED] msg33027/pgp0.pgp Description: PGP signature
Re: Dangerously Decidated yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the situation is that this table is required, and we're going to put it there. The reality of the situation is far from being clear. The only thing I can see is that you're trying to dictate things without adequate justification. You should reconsider that attitude. You can't substantiate your argument by closing your eyes, Greg. There's a wealth of evidence against your stance, and frankly, none that supports it other than myopic bigotry (I don't want to do this because Microsoft use this format). Are you going to stop using all of the other techniques that we share with them? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously Decidated yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
What is it about this particular topic brings out such irrational emotions in you and others? Because you define as irrational those opinions that don't agree with your own. I don't consider my stance irrational at all, and I find your leaps past logic and commonsense quite irrational in return. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: I guarantee you that there are a number of controllers which have different ideas of how to do soft sector sparing _at the controller level_ rather than at the drive level. We have dropped support for ESDI controllers long since. :-) Seriously, all the disks we are supporting these days do bad block replacement at the drive level. Adaptec 1742 is supported, though it took a long enough time to find its way into CAM. Same for the NCR 810. Neither of which do controller-level sparing. For certain applications, also, you _want_ to turn off the automatic bad sector sparing: it's incompatible with spindle sync, for example, where you want to spare all drives or none, so that the spindles don't desyncronize on a sparing hit for one drive, but not another. Spindle sync is an anachronism these days; asynchronous behaviour (write-behind in particular) is all the rage. You'd be hard-pressed to find drives that even support it anymore. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously dedicated yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
: IBM DTLA drives are known to rotate fast enough near the spindle : that the sustained write speed exceeds the ability of the controller : electronics to keep up, and results in crap being written to disk. I would adssume it actually the tracks FURTHEREST from the spindle.. With ZBR, anything is possible. Wouldn't the linear speed be faster closer to the spindle at 7200 RPM than at the edge? The stunning ignorance being displayed in this thread appears to have reached an all-time low. *sigh* -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: There shouldn't *be* bootblocks on non-boot disks. dd if=/dev/zero of=/dev/da$n count=1 Dont use disklabel -B -rw da$n auto. Use disklabel -rw da$n auto. All my disks have bootblocks and (spare) boot partitions. All the bootblocks are DD mode. I don't see any point in using obsolete fdisk tables. (There's IMHO only one purpose obsolete fdisk tables are good for, co-operation with other operating systems in the same machine. None of my machines uses anything else than FreeBSD.) Since I tire of seeing people hit this ignorant opinion in the list archives, I'll just offer the rational counterpoints. - The MBR partition table is not obsolete, it's a part of the PC architecture specification. - You omit the fact that many peripheral device vendors' BIOS code looks for the MBR partition table, and will fail if it's not present or incorrect. You do realise that DD mode does include a (invalid) MBR partition table (now valid, courtesy of a long-needed fix), right? I'd love to never hear those invalid, unuseful, misleading opinions from you again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
(The other day a coworker of mine wanted to use DD for some IBM DTLA disks, because he'd heard that the disks performed better that way - something to do with scatter-gather not working right unless you used DD. I'm highly skeptical about this since I have my own measurements from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they show the disks performing extremely well. Anybody else want to comment on this?) Since scatter-gather has nothing to do with the disk (it's a feature of the disk controller's interface to host memory), I think this coworker of yours is delusional. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question about Freebsd driver
I have a question about Freebsd driver. If we want to support some options in driver(like speed and duplex mode setting) , user can use this option to change driver configurations. I am not sure whether freebsd driver support driver parameter or something else. Can you give me some suggestions? Thanks!! From the question, I infer that you are referring to Ethernet device drivers. In the FreeBSD model, devices fit into one or more of a set of classes. Each class has an established, device-independant mechanism for controlling driver parameters. In the case of Ethernet drivers, parameters are controlled via the driver's ioctl interface. You should be able to find good examples of this in the source for other drivers similar to your own. If you have more specific questions, please feel free to ask them here. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously Decidated yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: personal opinion Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the situation is that this table is required, and we're going to put it there. End of story. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weird dump(8) messages
Maxim Sobolev [EMAIL PROTECTED] writes: DUMP: 75.00% done, finished in 0:11 DUMP: 79.58% done, finished in 0:10 DUMP: 86.22% done, finished in 0:07 DUMP: 93.22% done, finished in 0:03 DUMP: 105.07% done, finished in 0:-2 DUMP: 111.89% done, finished in 0:-6 DUMP: 122.01% done, finished in 0:-11 DUMP: 134.91% done, finished in 0:-18 ^^^ ^^^!!! DUMP: DUMP: 1299650 tape blocks DUMP: finished in 4454 seconds, throughput 291 KBytes/sec This is a 3GB partition with a standard 5-CURRENT, several packages and my development /usr/src and /usr/ports trees. Any ideas? What, you've never heard of giving a 110%? :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release breakage: src/sbin/ifconfig
Makoto Matsushita [EMAIL PROTECTED] writes: With 5-current as of Dec/04/2001 15:00:00 GMT. It seems that this is because 'WARNS=0' line is inside of !defined(RELEASE_CRUNCH) clause. IMO, if an application's code requires to set 'WARNS=0 for build, it should also be set when building as a part of a crunched binary. Should be fixed now. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: parallel port i/o hogs cpu badly; is this normal?
I don't know if there's a way to stop this, but it's normal, whenever I use my Parallel port zip drive, I have similar problems. There isn't, really. The parallel port is terribly inefficient. But what surprises me is that copying that data to the parallel intfc burns up an incredible amount of CPU. Until the document is printed, there's a steady bg buzz of ~10% CPU use, with periods of 50% and even 100% CPU utilization by the 'parallel'[1] process. The load is sufficient that it locks out the mouse on X (interrupt blocking?). Anyone care to comment? Does this sound normal? Is there a way to reduce the amount of CPU needed to drive the parallel port? Get a USB printer, or a USB-parallel adapter cable. It won't necessarily be much faster, but it will use a lot less CPU. The cables are pretty cheap ( $30), and they're mostly based on a single design that's known to work. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cardbus help
: As a workaround for you, though, try adjusting the memory that the driver : requests for the register window to be based at 0xf400. Actually, for most people, just ignoring the error is enough to make it work. This bothers me. Are bridges ignoring their mapping registers? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cardbus help
: : requests for the register window to be based at 0xf400. : : Actually, for most people, just ignoring the error is enough to make : it work. : : This bothers me. Are bridges ignoring their mapping registers? It would appaer that they are. It hurts my brain that it works. I don't mind it hurting my brain; it bothers me because if we try to toe the correctness line and nobody else (including the hardware) does, then we might find ourselves stuck in a corner we can't easily get out of in a hurry. However, I think the point is moot because in current I've fixed it to clip the ranges properly. That's definitely what I intended. I guess I should fix the typos in that file too, eh? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Archos 6000
i found a posting on the netbsd current mailinglist stating that with some minor modifications it sort of attached to the umass driver, but the author had no further success. the posting can be viewed at: http://www.geocrawler.com/archives/3/497/2001/7/100/6233506/ hope someone with the right knowledge takes this one on :) You might try forcing it to use the floppy command set; the ScanLogic USB:IDE adapter requires this despite claiming to be SCSI-compatible. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/conf files src/sys/dev/ciss ciss.c cissio.h cissreg.h cissvar.h src/sys/modules Makefile src/sys/modules/ciss Makefile src/sys/i386/conf NOTES
In message [EMAIL PROTECTED] Nickolay Dudorov writ es: : And I can buildkernel only after the next patch: I just removed this from build until Mike can fix the ciss driver itself. Sorry about this; I got distracted last night, and my last -current test build was too long ago. 8( I'll try to fix it tonight; in the meantime, where's that hat? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
So this means the output queue on my net card is full, right? And I guess there is no easy solution... Oh well, I'll have to cope. That's correct; the pipe is full, and you can't put any more bits in it. Typically you run into this situation when your app is generating more data than can squirt out the hole in your network card, or the card is stalled for some reason. Any app using socket I/O should be ready to handle ENOBUFS gracefully; it typically needs to pause and then retry the I/O. So, no solution, right? :( If the card is stalled (possible), then you may have a driver problem. But otherwise, it's not a problem except in the application. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. I am also attaching a tar.gz package which has the patch compressed and archived. This is NOT how to do this. File a PR containing the patch, and then post a reference to the PR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cardbus help
I'd like to get card bus working, however under 5.0-current my pcmcia controller is failing to load with the message: pccbb0: TI4451 PCI-CardBus Bridge at device 15.0 on pci2 pcib2: device pccbb0 requested unsupported memory randge 0x1000-0x (decoding 0xf400-0xfbff, 0xfff0-0xf) pccbb0: Could not grab register memory any insight? or will I have the pleasure of tinkering with the kerne? This is a bug in the way that the pccbb code allocates the register window when it hasn't been set up. The real fix actually requires the PCI code to configure the cardbus controller, but we don't do that yet (we desperately need to, though). As a workaround for you, though, try adjusting the memory that the driver requests for the register window to be based at 0xf400. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
