Re: umass driver speed
Was this ever committed? -Guido On Thu, Nov 28, 2002 at 01:53:26PM +0100, Nick Hibma wrote: Woohoo! Congrats. Nice job. If other people could test this, this should be committed. I'll have to have a quick look at the initialisation code that has been added to see whether there is no problem with that, but from the quick glance I just had, I don't think there is a prolbem in there. Nick Bingo! :) When I changed the bsqh initialisation, I get speed above 400 KB/s, that makes me feel much better :) I am sending a corrected patch as attachment. Tomas On Thu, 28 Nov 2002, Ian Dowse wrote: I had a quick look at the patch - one thing I noticed is that you are possibly not initialising all of the bsqh fields. In -current, bsqh-hlink and bsqh-qh.qh_hlink are set up to point at the `lsqh' QH. It might not be the problem though. Ian -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Guido van Rooij | Phone: ++31 653 994 773 Madison Gurkha, Technology Think-Tank | [EMAIL PROTECTED] | FreeBSD committer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
5.0-DP2 sparc64 buildworld problem
Hi all, I try to compile a kernel for a sparc64 on my FreeBSD 4.5 box. So I cvsup with: *default host=ftp.fr.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. #*default compress ## Main Source Tree. # # The easiest way to get the main source tree is to use the src-all # mega-collection. It includes all of the individual src-* collections. src-all ok, I have no problem with that. Then I cd to /usr/src and run: make TARGET_ARCH=sparc64 buildworld and I have the following error: === usr.bin/xargs /usr/obj/sparc64/usr/src/i386/usr/src/usr.bin/xargs created for /usr/src/usr.bin/xargs rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/xargs/xargs.c /usr/src/usr.bin/xargs/strnsubst.c echo xargs: /usr/lib/libc.a .depend cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/usr.bin/xargs/xargs.c cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/usr.bin/xargs/strnsubst.c cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -static -o xargs xargs.o strnsubst.o xargs.o: In function `prompt': xargs.o(.text+0xd15): undefined reference to `nl_langinfo' *** Error code 1 Stop in /usr/src/usr.bin/xargs. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src in stage 1 process. I tried to run these commands before: # chflags -R noschg /usr/obj/usr # rm -rf /usr/obj/usr # cd /usr/src # make cleandir # make cleandir but still have the same error. I guess that it isn't specific to TARGET_ARCH option because I tried to run the command without it and I still have this error. If someone has an idea or a better appropriated mailing lists and I would be very happy :-) Thanks in advance, [EMAIL PROTECTED] ps: I tried to run 'make TARGET_ARCH=sparc64' libraries before and in this case I have the following error: === gnu/lib/csu make -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/l ib/csu/../../../contrib/gcc tconfig.h echo 'struct rtx_def;' tconfig.h echo 'typedef struct rtx_def *rtx;' tconfig.h echo 'struct rtvec_def;' tconfig.h echo 'typedef struct rtvec_def *rtvec;' tconfig.h echo 'union tree_node;' tconfig.h echo 'typedef union tree_node *tree;'tconfig.h echo '' tconfig.h echo '#include ansidecl.h' tconfig.h echo '#include sparc/sparc.h' tconfig.h echo '#include dbxelf.h' tconfig.h echo '#include elfos.h'tconfig.h echo '#include freebsd-native.h' tconfig.h echo '#include freebsd-spec.h' tconfig.h echo '#include freebsd.h' tconfig.h echo '#include sparc/sysv4.h' tconfig.h echo '#include sparc/freebsd.h'tconfig.h echo '#include defaults.h' tconfig.h echo '#ifndef POSIX' tconfig.h echo '# define POSIX'tconfig.h echo '#endif'tconfig.h echo '#define CONFIG_SJLJ_EXCEPTIONS 0' tconfig.h rm -f .depend CC=cc MKDEP_CPP_OPTS=-M -DCRT_BEGIN mkdep -f .depend -a -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/usr/sr c/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /usr/sr c/gnu/lib/csu/../../../contrib/gcc/crtstuff.c /usr/src/gnu/lib/csu/../../../contrib/gcc/config/sparc/crtfastmath.c cc -O -pipe -mcpu=pentiumpro -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functi ons -fno-exceptions -fno-omit-frame-pointer -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -g0 -DCRT_BEGIN -c -o crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c In file included from /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:63: /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:37: field `array' has incomplete type /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:135: field `augmentation' has incomplete type /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:143:
Re: umass driver speed
No. According to N.Hibma, it needs more reviewing/testing, and noone had the time to do it yet. Tomas On Thu, 9 Jan 2003, Guido van Rooij wrote: Was this ever committed? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5.0-DP2 sparc64 buildworld problem
On Thu, Jan 09, 2003 at 08:55:17AM +0100, Julien Bournelle wrote: Hi all, I try to compile a kernel for a sparc64 on my FreeBSD 4.5 box. Then I cd to /usr/src and run: make TARGET_ARCH=sparc64 buildworld and I have the following error: === usr.bin/xargs /usr/obj/sparc64/usr/src/i386/usr/src/usr.bin/xargs created for /usr/src/usr.bin/xargs rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/xargs/xargs.c /usr/src/usr.bin/xargs/strnsubst.c echo xargs: /usr/lib/libc.a .depend cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/usr.bin/xargs/xargs.c cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/usr.bin/xargs/strnsubst.c cc -O -pipe -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -static -o xargs xargs.o strnsubst.o xargs.o: In function `prompt': xargs.o(.text+0xd15): undefined reference to `nl_langinfo' *** Error code 1 Stop in /usr/src/usr.bin/xargs. *** Error code 1 but still have the same error. I guess that it isn't specific to TARGET_ARCH option because I tried to run the command without it and I still have this error. I think you must upgrade your box into 4.7-RELEASE (or RELENG_4_) at first, then one more time try build world for sparc64. -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-06 17:36:52 +0100: ! Background: This environment should be configured to use ! an internet connection for internet-relevant things, but to ! work flawlessly without such a connection as long as matters ! do concern only systems within the LAN. ! ! This is called a split horizon DNS, and you need to run two ! DNS servers, one interior, and one exterior, both authoritative ! for your domain, in order for this to work. The problem is that ! you are forwarding a request that should be local, and you are ! doing it because your local server does not pass the authority ! test for your local domain. Well, I think I got it now. What I did not know was that any nameserver installation is expected to always have some kind of root nameserver accessible (either the real ones from the internet, or elseways a local shortcut) in order to function properly. This is wrong in at least two ways. An authoritative content server doesn't need to know root servers, because they're out of it's business. A non-recursive (forwarding-only) resolver doesn't need to know root servers, just the upstream resolver it forwards all requests to. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Exceptions via setjmp/longjmp in kernel.
Hello hackers... I got strange problem when trying to implement something like exceptions with setjmp()/longjmp() functions. [...] int ret; jmpbuf buf; [...] ret = setjmp(buf); KASSERT(ret != 1, (I never return 1 with longjmp().)); [...] longjmp(buf, value_diffrent_than_1); [...] And setjmp() returns only 0 or 1 (when longjmp() is called), but never returns value that I've put in longjmp() call. There could be some other problems in using setjmp()/longjmp() in kernel? I'm paying attention on memory leaks and locks that are done before longjmp(). -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Exceptions via setjmp/longjmp in kernel.
On Thu, Jan 09, 2003 at 03:30:59PM +0100, Pawel Jakub Dawidek wrote: I got strange problem when trying to implement something like exceptions with setjmp()/longjmp() functions. [...] int ret; jmpbuf buf; [...] ret = setjmp(buf); KASSERT(ret != 1, (I never return 1 with longjmp().)); [...] longjmp(buf, value_diffrent_than_1); [...] And setjmp() returns only 0 or 1 (when longjmp() is called), but never returns value that I've put in longjmp() call. There could be some other problems in using setjmp()/longjmp() in kernel? I'm paying attention on memory leaks and locks that are done before longjmp(). The usage of the setjmp macro in an assignment is not defined by ISO C, which might or might not be your problem. 7.13.1.1 The setjmp macro An invocation of the setjmp macro shall appear only in one of the following contexts: -- the entire controlling expression of a selection or iteration statement; -- one operand of a relational or equality operator with the other operand an integer constant expression, with the resulting expression being the entire controlling expression of a selection or iteration statement; -- the operand of a unary ! operator with the resulting expression being the entire controlling expression of a selection or iteration statement; or -- the entire expression of an expression statement (possibly cast to void). OTOH, vinum and ficl use setjmp in the same way. Stefan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Exceptions via setjmp/longjmp in kernel.
Apparently, On Thu, Jan 09, 2003 at 03:30:59PM +0100, Pawel Jakub Dawidek said words to the effect of; Hello hackers... I got strange problem when trying to implement something like exceptions with setjmp()/longjmp() functions. [...] int ret; jmpbuf buf; [...] ret = setjmp(buf); KASSERT(ret != 1, (I never return 1 with longjmp().)); [...] longjmp(buf, value_diffrent_than_1); [...] And setjmp() returns only 0 or 1 (when longjmp() is called), but never returns value that I've put in longjmp() call. There could be some other problems in using setjmp()/longjmp() in kernel? I'm paying attention on memory leaks and locks that are done before longjmp(). The kernel longjmp only ever seems to return 1. See i386/i386/support.s. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Exceptions via setjmp/longjmp in kernel.
On Thu, Jan 09, 2003 at 11:03:55AM -0500, Jake Burkholder wrote: + The kernel longjmp only ever seems to return 1. See i386/i386/support.s. That's right, thanks! But this is strange, setjmp/longjmp are defined in C99 and there setjmp() returns value from longjmp(). -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
! Exactly. And when this is not found, then the resolver will
! inplicitly issue another query for the unqualified name.
!
! And it is even worse with sendmail, because sendmail does quite
! interesting things there - like switching off RES_DEFNAMES -
! so this one will definitely not add the local domain.
!
! This is broken in 2 ways:
Hmm... possibly.
! 1)The default names option in the standard resolver will prevent
! another query for the unqualified name, since unqualified names
! are supposed to get the local domain name, unconditionally.
I'm sorry, my named.log shows it the other way round - as does
the debug mode of nslookup:
$ nslookup
Default Server: localhost.oper.dinoex.org
Address: 127.0.0.1
set debug
wurz [defnames is set by default]
Server: localhost.oper.dinoex.org
Address: 127.0.0.1
;; res_nmkquery(QUERY, wurz.oper.dinoex.org, IN, A)
Got answer:
HEADER:
opcode = QUERY, id = 56443, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
wurz.oper.dinoex.org, type = A, class = IN
AUTHORITY RECORDS:
- oper.dinoex.org
ttl = 3600 (1H)
origin = disp-e.oper.dinoex.org[this is localhost]
mail addr = admin.disp.oper.dinoex.org [this is me]
serial = 20011217
refresh = 3600 (1H)
retry = 900 (15M)
expire = 360 (5w6d16h)
minimum ttl = 3600 (1H)
;; res_nmkquery(QUERY, wurz, IN, A)
timeout [here it starts dialing out!]
Got answer:
HEADER:
opcode = QUERY, id = 56444, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
wurz, type = A, class = IN
AUTHORITY RECORDS:
- (root)
ttl = 10800 (3H)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2003010801
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
*** localhost.oper.dinoex.org can't find wurz: Non-existent host/domain
set nodefnames
wurz
Server: localhost.oper.dinoex.org
Address: 127.0.0.1
;; res_nmkquery(QUERY, wurz, IN, A)
Got answer:
HEADER:
opcode = QUERY, id = 56445, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
wurz, type = A, class = IN
AUTHORITY RECORDS:
- (root)
ttl = 10701 (2h58m21s)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2003010801
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
*** localhost.oper.dinoex.org can't find wurz: Non-existent host/domain
--
! 2)It's possible to change the resolver flags in sendmail by
! adding lines to the M4 file source code. You need to look
! at the source tree and read cf/README.
Been there, done it, got the t-shirt. I walked thru the whole
code there, only to find lots of niceies like the following
- from daemon.c:
-
if (host[0] == '[')
{
[some stuff deleted]
}
else
{
/* contortion to get around SGI cc complaints */
{
p = host[strlen(host) - 1];
hp = sm_gethostbyname(host, family);
if (hp == NULL *p == '.')
{
# if NAMED_BIND
int oldopts = _res.options;
_res.options = ~(RES_DEFNAMES|RES_DNSRCH);
# endif /* NAMED_BIND */
*p = '\0';
hp = sm_gethostbyname(host, family);
*p = '.';
# if NAMED_BIND
_res.options = oldopts;
# endif /* NAMED_BIND */
}
}
-
Now this looks correct, because the second call to
sm_gethostbyname hits only on FQDNs with terminating dot
- but then sm_gethostbyname() in conf.c will not care
about the resolver-flags at all and will shorten all
unresolveable hostnames that do not have a terminating
dot to their first component and retry with that.
So even if we have a full qualified hostname with
terminating dot, it will end up with a resolver query
for the first name component - and that gets treated
just like in the debug log above.
Now, as far as I am considered, I think I have had enough of this
stuff. I have understood from the
Re: Exceptions via setjmp/longjmp in kernel.
On Thu, Jan 09, 2003 at 05:25:20PM +0100, Pawel Jakub Dawidek wrote: On Thu, Jan 09, 2003 at 11:03:55AM -0500, Jake Burkholder wrote: + The kernel longjmp only ever seems to return 1. See i386/i386/support.s. That's right, thanks! But this is strange, setjmp/longjmp are defined in C99 and there setjmp() returns value from longjmp(). setjmp/longjmp are defined in C99 for *hosted* C implementations. When compiling a kernel one is almost certainly using a freestanding C implementatio, which basically means that there are only a few library facilities that need be present. Setjmp/longjmp is not among them. This means that for the kernel setjmp/longjmp the C standard has nothing to say about their behaviour. It might of course be desirable to make them work the same as the standard facilities as far as it is practical, but it is not always practical. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
On 09-Jan-2003 Terry Lambert wrote: Julian H. Stacey wrote: Terry Lambert wrote: Because RC2 was not tagged, because We Fear CVS Tags(tm), you will need to use a date in order to create your own RC2. Perhaps release build team are trying to avoid touching every file in the CVS tree, as global touching costs people receiving on modems non flat rate extra telecom charges, (regardless of whether receiving via CVSup or CTM etc). I'm well aware of that (see other post). RC2 seems important though; so Although there's no tag in src/Makefile,v is there a CVS file containing a table of dates corresponding to EG RC2, RC1 etc ? ( if one doesnt exist, how about creating one ?). RC2 has additional changes, above and beyond a simple date tag (see other post; I believe it was managed in P4, and you could use _that_ to recover it). A tag, in this case, would only be useful if the other RC2 changes (string changes, hacks to suppress known bugs, etc., mostly) were made in a branch off the tag, in the main source tree, rather than in P4. Not a convenient option, all around, I'm afraid, though I agree that release candidates should be tagged in the tree, so they can be recovered, for archival reasons, if nothing else. 8-(. This is incorrect. Only DP1 and DP2 have diff's relative to current. The RC's are cut directly from -current. The main point, though, is about getting the same sources for the RC2 that won't install, in order to build an RC2 that's identical, so it won't install, and then build an RC2 with a kernel with symbols and DDB and BREAK_TO_DEBUGGER, so we can find out *why* it won't install. These bits are quite easily obtained from the tarballs in the RC2 release that are available both via FTP and on the CD. :) -- 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-hackers in the body of the message
Re: Exceptions via setjmp/longjmp in kernel.
how do you ensure that the thread doesn't own any locks when it does the longjmp? On Thu, 9 Jan 2003, Pawel Jakub Dawidek wrote: Hello hackers... I got strange problem when trying to implement something like exceptions with setjmp()/longjmp() functions. [...] int ret; jmpbuf buf; [...] ret = setjmp(buf); KASSERT(ret != 1, (I never return 1 with longjmp().)); [...] longjmp(buf, value_diffrent_than_1); [...] And setjmp() returns only 0 or 1 (when longjmp() is called), but never returns value that I've put in longjmp() call. There could be some other problems in using setjmp()/longjmp() in kernel? I'm paying attention on memory leaks and locks that are done before longjmp(). -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
¢³øL¦ Ƚ̡NÌ^¨
*This message was transferred with a trial version of CommuniGate(tm) Pro*
(BMÒ
(Bdq[LÐ
(B
(B¡ãALð²ó]³êÈ¢ûͱ±Ö
([EMAIL PROTECTED]
(BK¸{¶É ȽÌ[AhXÌÝ𨫺³¢
(B
(B
(B§104-0061
(BsæâÀ8-19-3
(Bæ2ECOr@3F
(B[}KWs
(B
(BTEL@001-373-188-8477
(BFAX@03-3544-6218@@
(B
(B
(B\\\\\\\\\\\\\\\\\\
(B
(B rfIÌEÁê_b`CtErlNu
(B`ujDåWErdwthEA_gObYÈÇ
(B @A_gÖAÌîñÚ@
(B
(B
(B¨\ÝE²¶E¤iÚ×Í@
(BºLtqkðNbNµÄ²º³¢B
(B
(B«@@@@«@@@@«@
(Bhttp://pink.webhop.info/
(B
(B\\\\\\\\\\\\\\\\\\
(B
(BJ^ObYEÉéîñEhÆObYEàׯîñÈÇ@
(B@@@@»Ì¼îñÚ@
(B
(B
(B¨\ÝE²¶E¤iÚ×Í@
(BºLtqkðNbNµÄ²º³¢B
(B
(B«@@@@«@@@@«@
(Bhttp://white.webhop.biz/
(B
(B\\\\\\\\\\\\\\\\\\
(B
(B
(BTo Unsubscribe: send mail to [EMAIL PROTECTED]
(Bwith "unsubscribe freebsd-hackers" in the body of the message
Re: Multi-threaded or async Mozilla (NSPR, really)
On Mon, 30 Dec 2002, D J Hawkey Jr wrote: Without checking, I'll take your word for it. But if so, what are they doing in libc_r? I thought that was for re-entrant/thread-safe functions? Is there an appreciable difference between re-entrant and thread-safe? My understanding is that libc_r is for all functions from libc plus thread-oriented functions, with many, but not all, functions from libc having wrappers/being re-written/having *_r companions for thread-safety. -- Andriy Gapon * Broadcast Message from wnpdev21 (pts/tg) Wed Jan 8 09:12:47... replacing the jar - krishna 3931 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Exceptions via setjmp/longjmp in kernel.
On Thu, Jan 09, 2003 at 10:51:13AM -0800, Julian Elischer wrote: + how do you ensure that the thread doesn't own any locks when it does the + longjmp? Hmm, hard to explain. I got my own infrastructure for this and every locks that are done I got in my-threads, so I just have to check those thread when setjmp() returns value != 0 and release them. I got also my own functions for locking/unlocking data based on tsleep()/wakeup_one() functions. For now this works only on 4.x, but I want to be prepare for 5.x (but I don't understand mutexes handling for now). Also... I got setjmp() only in one place and when I'm returning with longjmp() I need to just unlock everything that was locked between setjmp() and longjmp() and this is easy, because every lock is stored in my-thread structure. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: umass driver speed
Tomas Pluskal wrote: On Thu, 9 Jan 2003, Guido van Rooij wrote: Was this ever committed? No. According to N.Hibma, it needs more reviewing/testing, and noone had the time to do it yet. One workaround would be to draft volunteers... by committing it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
rfork DoS
I think there can be a problem if we allow rfork without either RFCFDG or RFFDG and RFTHREAD. Basically because we cache the ADVLOCK flag in the proc we may have a situation where this happens: p1 rfork(RFMEM); /* gets back p2 */ p2 advlocks some files from the shared table p2 exits, but since the refcount on the fdesc is still 0 we leave it alone and leak lock structures. p1 exits Does this make sense as a problem area? I think we should only allow filedesc sharing if RFTHREAD is set. RFTHREAD seems to get it right because of the peers/leader mechanism. thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rfork DoS
Well, the manual page (which may be out of date) infers that the rfork() only operates on the current process if RFPROC is not set. If we extend that to include RFTHREAD then the inference is that either RFPROC or RFTHREAD must be set and if neither is set an error should be returned. Am I missing something? -Matt Matthew Dillon [EMAIL PROTECTED] :I think there can be a problem if we allow rfork without :either RFCFDG or RFFDG and RFTHREAD. : :Basically because we cache the ADVLOCK flag in the proc :we may have a situation where this happens: : :p1 rfork(RFMEM); /* gets back p2 */ :p2 advlocks some files from the shared table :p2 exits, but since the refcount on the fdesc is still 0 we leave it : alone and leak lock structures. :p1 exits : :Does this make sense as a problem area? I think we should only :allow filedesc sharing if RFTHREAD is set. RFTHREAD seems to get :it right because of the peers/leader mechanism. : :thanks, :-- :-Alfred Perlstein [[EMAIL PROTECTED]] :'Instead of asking why a piece of software is using 1970s technology, : start asking why software is ignoring 30 years of accumulated wisdom.' : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rfork DoS
* Matthew Dillon [EMAIL PROTECTED] [030109 12:37] wrote: Well, the manual page (which may be out of date) infers that the rfork() only operates on the current process if RFPROC is not set. If we extend that to include RFTHREAD then the inference is that either RFPROC or RFTHREAD must be set and if neither is set an error should be returned. Am I missing something? That sounds right. The only reason I didn't go that far was because I wasn't sure if we wanted to allow shared sigacts without leadership. I think that it would be safest to require userland to set either RFPROC or RFTHREAD. Yes, the manpage is out of date. What the hell is a sigact anyhow? Can someone please fixup the manpage? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
John Baldwin wrote: The main point, though, is about getting the same sources for the RC2 that won't install, in order to build an RC2 that's identical, so it won't install, and then build an RC2 with a kernel with symbols and DDB and BREAK_TO_DEBUGGER, so we can find out *why* it won't install. These bits are quite easily obtained from the tarballs in the RC2 release that are available both via FTP and on the CD. :) Which he can't access because RC2 won't install for him. Pay attention. 8-) 8-). Basically, he needs to get to building RC2 on a machine that can't install RC2. I've already mentioned using disk #2 (not sure if it exists for RC2), and/or unpacking the tar archives for the source parts manually from disk #1. It's preferrable to be able to do this from a CVS tree, though, since there might be a fix in the source tree since the RC2 was cut, which will fix his problem. Otherwise, he has to reinvent it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Roman Neuhauser wrote: ! This is called a split horizon DNS, and you need to run two ! DNS servers, one interior, and one exterior, both authoritative ! for your domain, in order for this to work. The problem is that ! you are forwarding a request that should be local, and you are ! doing it because your local server does not pass the authority ! test for your local domain. Well, I think I got it now. What I did not know was that any nameserver installation is expected to always have some kind of root nameserver accessible (either the real ones from the internet, or elseways a local shortcut) in order to function properly. This is wrong in at least two ways. An authoritative content server doesn't need to know root servers, because they're out of it's business. The authoritative server must also be a forwarding server. This is because of both the way the resolver library itself works (single preference), and the fact that on a border router, you have only a single IP address on which to bind a DNS service, and therefore can offer only a single DNS service to interior machines. While technically, some UNIX clients permit multiple definitaions in this case, practically, you can't take advantage of this, because you must deal with interior Windows clients machines, where this is not permitted. A non-recursive (forwarding-only) resolver doesn't need to know root servers, just the upstream resolver it forwards all requests to. Realize that this is not possible, with the current resolver library, since all programs will reference the single /etc/resolv.conf. If you reference a completely authoritative interior server, with no forwarding, and the resolver stops there, then the exterior server is not referenced. This is complicated, both as noted above, for Windows clients (it would require a second IP address on the interior network, minimally, to resolve), and by the fact that the IP address of the external interface is unknown until after link-up, which will generally occur well after the DHCP lease is granted to interior machines. This is even urther complicated by the fact that the DHCP server is likely to be a Windows Primary Domain Controller, and therefore not the border device, itself. Note that even though your resolver is internally authoritative, for the Internet's view of the world, an external resolver for the domain is likly authoritative, instead. Specifically, you will be running hosted primary for www.example.com and for the MX records for example.com. The only way for this to actually work is to split the authority for the example.com domain between two nameservers -- one interior, and one exterior. Partial delegation is simply not supported by the current DNS model. The problem comes down to round-tripping local changes to the DNS, e.g. DHCP leases, etc.. If you can solve the round-tripping problem, you can, in fact, deal with this via the DNSNOT mechanism. Unfortuanately, a transiently connected DNS server will not receive notifications from a primary DNS server, particularly when it is offline, but also for any state changes occurring while it is offline, unless it attempts a zone transfer (e.g. on link up). Zone transfers are not desirable in this case, since the authority is split; the closes you can get is a blind secondary. To implement a blind secondary requires modification of the DNS server secondary declaration mechanism, to result in a serach from root by the secondary server, in order to locate the primary for the domain being served. For this to work, the syntax of the declaration of a secondary must be changes, and a zone transfer attempted on linkup. The syntax of a blind secondary is defined at: Blind Secondary DNS Extension draft-lambert-dns-bsec-00.txt ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-bsec-00.txt It is a trivial change, but can increase the root load. The way to avoid this is to mandate caching, and only transit to the root if the name server is not where it was previously (e.g. as a result of an ISP reconfiguration while the secondary was offline). An expiration time for the cache is not relvent, in that this has to do with claim of authority; if the SOA is stale, then it serves as the timeout. In addition to this, to resolve authority issues, we have to recognize the seperation of control between transiently and non-transiently connected servers. I did not mention this before, since the problem under discussion was how to *avoid* lookups, requiring a link-up operation, for fully qualified DNS names which were not defined locally; making this modification requires careful reconfiguration. Specifically, the external primary is considered to be in a delegated subdomain of the locally authoritative domain; for lookups direct to the name server, the subdomain is implied in the operation. This, too, requires a modification of the DNS server implementation. The simplest
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Peter Much wrote: ! 1)The default names option in the standard resolver will prevent ! another query for the unqualified name, since unqualified names ! are supposed to get the local domain name, unconditionally. I'm sorry, my named.log shows it the other way round - as does the debug mode of nslookup: What are the precise contents of your /etc/resolv.conf? ! 2)It's possible to change the resolver flags in sendmail by ! adding lines to the M4 file source code. You need to look ! at the source tree and read cf/README. Been there, done it, got the t-shirt. I walked thru the whole code there, only to find lots of niceies like the following - from daemon.c: [ ... ] Now, as far as I am considered, I think I have had enough of this stuff. I have understood from the code why it behaves the way it does, have learned a bit about name resolution, and now either have to live with it the way it is, or change the code in a way I like. Naturally, I personally believe all problems are solvable, and Greg can answer on the resolution of names in sendmail for this second case, but I understand your losing interest. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
Bruce A. Mah wrote: RC2 has additional changes, above and beyond a simple date tag (see other post; I believe it was managed in P4, 5.0-RC2 was assembled out of CVS, not P4. Terry, please check your facts before posting. My bad; this was already corrected by another poster, who pointed out that P4 was used for the developer prereleases, but that the RC was out of the CVS tree. I didn't think it needed pointing out again, but if you do... The RC2 was cut from the CVS tree. and you could use _that_ to recover it). A tag, in this case, would only be useful if the other RC2 changes (string changes, hacks to suppress known bugs, etc., mostly) were made in a branch off the tag, in the main source tree, rather than in P4. Once again, 5.0-RC2 didn't have a darn thing to do with P4. I'm also unaware of any other RC2 changes. I was under the impression that the version string carried RC2 in it; I'm willing to be mistaken. I thought there were also manual additions to the CDROM, such that it wasn't a pure built from source tree thing. My personal approach would be to use the souce tree from disk #2 (if one was made for the 5.0-RC2 distributions) 5.0-RC2-i386-disc1.iso contains 75M of compressed src/ 5.0-RC2-i386-disc2.iso /usr/src is empty. Disk #1 should have various compressed subtrees of src/ compressed (for use by sysinstall). Those should work well. What Terry may be referring to is the fact that for full releases, disk #2 usually contains a compressed copy of the CVS repository. Yes, and yes. The CVS tree on disk #2 is a compressed snapshot of the source tree at the time. It's much more useful than the sources on disk #1, both because you have to know what you are doing to use the source on disk #1, and because you can CVSup it, get a relatively small delta (so it doesn't take a long time), and pick up any fixes that happened after the RC2 was cut. For example, Kirk checked in a UFS panic fix right after RC2 was cut, that might be the panic in this thread. There's no way to know, though, until the person with the panic repeats their panic during upgrade into the kernel debugger, and asks it where the panic happened. Basically, we are getting into all this esoteric stuff because someone has a bug that the rest of us can't repeat, and the only way it's going to get fixed is if the person seeing it does some extra work. Arguably, for releases, there should probably be an image on the CDROMs that would never fit on a floppy, and has the debugger on it, with symbols in the kernel, to let people debug things like this. I expect if that ever happens, it won't be the default distribution, anyway. In any case, that's what we've been telling the guy to build, in order to debug his upgrade problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
If memory serves me right, Terry Lambert wrote: Bruce A. Mah wrote: and you could use _that_ to recover it). A tag, in this case, would only be useful if the other RC2 changes (string changes, hacks to suppress known bugs, etc., mostly) were made in a branch off the tag, in the main source tree, rather than in P4. Once again, 5.0-RC2 didn't have a darn thing to do with P4. I'm also unaware of any other RC2 changes. I was under the impression that the version string carried RC2 in it; I'm willing to be mistaken. I thought there were also manual additions to the CDROM, such that it wasn't a pure built from source tree thing. Ah, OK. It sounded to me like you meant we checked out src/ and then tweaked it a bunch (in P4 or locally) before rolling the snapshot. For the benefit of everyone else, it doesn't work that way. 5.0-RC2 comes from explicitly setting the BUILDNAME variable during make release. The only things that get added manually afterwards are: 1) packages and 2) the DOS utilities such as fdimage.exe. Arguably, for releases, there should probably be an image on the CDROMs that would never fit on a floppy, and has the debugger on it, with symbols in the kernel, to let people debug things like this. I expect if that ever happens, it won't be the default distribution, anyway. In any case, that's what we've been telling the guy to build, in order to debug his upgrade problem. H. It doesn't sound impossible to do, but it almost certainly won't happen for 5.0. For the DPs we built debug kernels on the ISO images (in addition to the regular GENERIC kernels), but I can't remember if they fit the requirements of what you listed above. I remember setting a variable for make release to do this, but it was otherwise automated. Bruce. PS. If the original poster is still following this, 5.0-RC3 snapshots are going to start building hopefully in the next 12 hours (awaiting an MFC of some ata(4) fixes from sos@). msg39111/pgp0.pgp Description: PGP signature
buffer management questions
Hi,everybody, I do not know the KVA real means what. From internet, I only know it is kernel address space. In buf structure, there are two members about KVA - b_kvabase b_kvasize; And when the buf management works, it will remove/add a buf from one queue to another, one instance, based on b_kvasize, a buf can be moved form QUEUE_DIRTY to QUEUE_EMPTYKVA or QUEUE_EMPTY(i.e: brelse function). So, what is the difference between the two empty queue? Another question, the buf queues have one QUEUE_NONE queue, I do not know how the QUEUE_NONE queue works. When buf init, all buffers will be added to QUEUE_EMPTY. I reference the 5.0RC2 source. Thank you! Best Regards Ouyang Kai _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
solaris firewall?
how well of a firwall can be created with Solaris 8 I am playing with a couple different *nix flavors and wanted to test out setting up a Solaris firewall is it possible and how would I do it..any Ideas. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: solaris firewall?
On Thursday, Jan 9, 2003, at 23:41 US/Pacific, Shawn Henderson wrote: how well of a firwall can be created with Solaris 8 I am playing with a couple different *nix flavors and wanted to test out setting up a Solaris firewall is it possible and how would I do it..any Ideas. Posting to a Solaris list would be job one. KeS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
On Thu, Jan 09, 2003 at 12:07:19PM -0800, Terry Lambert wrote: ! What are the precise contents of your /etc/resolv.conf? search oper.dinoex.org nameserver 127.0.0.1 nameserver 192.168.98.2 rgds, PMc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
Terry Lambert wrote: Julian H. Stacey wrote: Terry Lambert wrote: Because RC2 was not tagged, because We Fear CVS Tags(tm), you will need to use a date in order to create your own RC2. RC2 seems important though; so Although there's no tag in src/Makefile,v is there a CVS file containing a table of dates corresponding to EG RC2, RC1 etc ? ( if one doesnt exist, how about creating one ?). RC2 has additional changes, above and beyond a simple date tag (see other post; I believe it was managed in P4, Is P4 your shorthand for `PerForce' ? Some commercial software most of us don't have ? Do you think FreeBSD release builders may be using that to assemble 5.0 src/ ? and you could use _that_ to recover it). A tag, in this case, would only be useful if the other RC2 changes (string changes, hacks to suppress known bugs, etc., mostly) were made in a branch off the tag, in the main source tree, rather than in P4. Repeat Question for release engineers please: What is the cvs syntax, or where is the date documented in cvs/ , to extract RC2 src/ ? when cvs/ tree is local it's unattractive to need to ftp either ISOs, or ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.0-RC2/src/ My personal approach would be to use the souce tree from disk #2 (if one was made for the 5.0-RC2 distributions) 5.0-RC2-i386-disc1.iso contains 75M of compressed src/ 5.0-RC2-i386-disc2.iso /usr/src is empty. Julian Stacey jhs @ berklix.com Computer Systems Engineer, Unix Net Consultant, Munich. Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. Munich BSD Conference:http://berklix.org/conf/ Spam phrases triggering deletion: http://berklix.com/jhs/mail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
