Re: PPPD+PAM
> Hey markm, ya wanna add this to your to-do list? :-) Added :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Tue, 31 Aug 1999, Mark Murray wrote: > This _may_ be a solution to a problem I am having with SSH on a > congested link; I don't get my characters back until I hit a bunch > of characters (it appears that they are stuck in an outbound buffer > untill then. The problem only happens on congested links with SSH, > and is somewhat random but repeatable. I see this on some Alphas running OSF/1 - when I'm logged in remotely via rlogin or telnet it will often pause output until I hit another key. I put it down to misconfiguration of the system somehow.. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
> If you don't know that they are, you don't need to worry about them. :-) > > Seriously, they are allow finer control over some of the TCP behavior. > > delacktime is related to Nagle's algorithm, and specifies how long a > system should delay ACK'ing a packet in hopes that it can collect some > data from ther user and piggyback it on top of the ACK packet. This _may_ be a solution to a problem I am having with SSH on a congested link; I don't get my characters back until I hit a bunch of characters (it appears that they are stuck in an outbound buffer untill then. The problem only happens on congested links with SSH, and is somewhat random but repeatable. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multipatch #8 available
I've spent several hours resyncing the source tree and revalidating the patchset (though w/ the buildworld breakage revalidation was not entirely complete). Multipatch #8 is now available. http://www.backplane.com/FreeBSD4/ This patch contains a controversial backouts which I explain in the documentation on my site. I hope to see a resolution by committers on the issues relating to this controversy but in the mean time I am keeping my patch synchronized to the source tree and containing what I believe to be appropriate so the 12+ people I know are using it can continue to use it without having to go through loops. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
>> How about struct timeval instead? Timevals shouldn't be used in new interfaces. Use timespecs, which are both Standard and more future proof. >Firstly we are talking about time deltas, and on the sysctl side of things >it's very hard to set 'timevals (as you'd need to set two different >variables) so you need a single value on teh userland side of things. sysctl can handle structs. The problems are that sysctl(8) has little or no support for inputting structs, and timespec units might be inconvenient (sysctl -w kern.quantum=0.00100 vs sysctl -w kern.quantum=1). We already use microseconds instead of nanoseconds for kern.quantum because nanoseconds resolution is unwieldy and not needed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Aug 08, 1999 at 10:23:01PM -0400, Chris D. Faulhaber wrote: > Does this have anything to do with the current (no pun intended) breakage: > > /usr/src/usr.sbin/trpt/trpt.c:358: `TCPT_REXMT' undeclared (first use in Yes; I forgot to commit the patch to remove references to the timers in this program; I just fixed it. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
Does this have anything to do with the current (no pun intended) breakage: ===> usr.sbin/trpt cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/trpt/trpt.c /usr/src/usr.sbin/trpt/trpt.c: In function `main': /usr/src/usr.sbin/trpt/trpt.c:196: warning: passing arg 4 of `qsort' from incompatible pointer type /usr/src/usr.sbin/trpt/trpt.c: In function `dotrace': /usr/src/usr.sbin/trpt/trpt.c:237: warning: passing arg 3 of `tcp_trace' from incompatible pointer type /usr/src/usr.sbin/trpt/trpt.c:247: warning: passing arg 3 of `tcp_trace' from incompatible pointer type /usr/src/usr.sbin/trpt/trpt.c: In function `tcp_trace': /usr/src/usr.sbin/trpt/trpt.c:354: `TCPT_NTIMERS' undeclared (first use in this function) /usr/src/usr.sbin/trpt/trpt.c:354: (Each undeclared identifier is reported only once /usr/src/usr.sbin/trpt/trpt.c:354: for each function it appears in.) /usr/src/usr.sbin/trpt/trpt.c:355: structure has no member named `t_timer' /usr/src/usr.sbin/trpt/trpt.c:357: structure has no member named `t_timer' /usr/src/usr.sbin/trpt/trpt.c:358: `TCPT_REXMT' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/usr.sbin/trpt. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cvsupped about an hour ago (2115 EST)...I just recvsupped, no applicable changes. - Chris D. Faulhaber <[EMAIL PROTECTED]> | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPD+PAM
In article <[EMAIL PROTECTED]>, Andrea Franceschini <[EMAIL PROTECTED]> wrote: > > I'm trying to use pppd coupled with PAM. > I'm using pppd 2.3.9 compiled with USE_PAM options ,and ,as far as i can see ,the > pppd side seem to work fine,but when i try to use the PAM side i got this: > > - > Aug 29 18:22:06 volcano pppd[1643]: rcvd [PAP AuthReq id=0x1 user="*" passwo > rd="*"] > Aug 29 18:22:06 volcano pppd[1643]: unable to resolve symbol: pam_sm_open_session Sorry, our pam_unix module doesn't support the "session" feature currently. Hey markm, ya wanna add this to your to-do list? :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Mon, 30 Aug 1999, Peter Dufault wrote: > > there are very few values that could make sense in both Hours scale and > > usecs scale.. > > > > thus items that could be small could be in uSecs and items that could > > be big could be in Secs.. A small set of functions could be used to > > make this uniform through the system > > > > syscall_Secs_to_hz(ulong *ticks, boolean Allow_zero SYSCTL_HANDLER_ARGS) > > syscall_mSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) > > syscall_uSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) > > How about struct timeval instead? Firstly we are talking about time deltas, and on the sysctl side of things it's very hard to set 'timevals (as you'd need to set two different variables) so you need a single value on teh userland side of things. Inside the kernel it's all done in ticks, so you should store that. thus having chosen the two units for internal and external, the function almost defines itself. julian > > Peter > > -- > Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, > HD Associates, Inc. Safety critical systems, Agency approval > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Perl broken in 4.0-CURRENT ?
I get the following errors when trying to run certain perl stuff .. like mirror: su-2.03# mirror /usr/local/lib/mirror/packages/daemonnews DynaLoader:/usr/libdata/perl/5.00503/DynaLoader.pm:188 Caught a SIGSEGV shutting down at /usr/local/bin/mirror line 3873. uname -a: FreeBSD shadowmere.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #15: Mon Aug 30 11:35:46 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/VANADIUM i386 Pascal Hofstee - [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP-- t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
> there are very few values that could make sense in both Hours scale and > usecs scale.. > > thus items that could be small could be in uSecs and items that could > be big could be in Secs.. A small set of functions could be used to > make this uniform through the system > > syscall_Secs_to_hz(ulong *ticks, boolean Allow_zero SYSCTL_HANDLER_ARGS) > syscall_mSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) > syscall_uSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) How about struct timeval instead? Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Tue, 31 Aug 1999, Peter Jeremy wrote: > Jonathan Lemon <[EMAIL PROTECTED]> wrote: > >On Aug 08, 1999 at 03:01:32PM -0700, Julian Elischer wrote: > >> I don't want to sound ungrateful, but couldn't we have defined these in > >> terms of Usecs and translated? > ... > > I think that having it in units of usec is > >probably better than msec; it provides more in the way of > >"forward compatability", > > Given a 32-bit integer, it also puts a much lower limit on the > maximum. This is likely to bite on TCP keep-alives - currently they > are set to 2 hours. We can't represent 2 hours as usecs in 32 bits. > > > and allows for a larger HZ. > > Not really. The only problem is that the rounding errors get more > noticable as the number of units approaches HZ. This is an artifact > that should be pointed out in the description - eg if you ask for > 2msec on an Alpha, you'll probably get 1.66msec. there are very few values that could make sense in both Hours scale and usecs scale.. thus items that could be small could be in uSecs and items that could be big could be in Secs.. A small set of functions could be used to make this uniform through the system syscall_Secs_to_hz(ulong *ticks, boolean Allow_zero SYSCTL_HANDLER_ARGS) syscall_mSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) syscall_uSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) > > Peter > > > 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
buildworld fail
I'm getting this for a couple of builds with today's code : t_terminal_io': terminal.o(.text+0x1e4): undefined reference to `tgetent' terminal.o(.text+0x2c2): undefined reference to `tgetstr' terminal.o(.text+0x34e): undefined reference to `tgetflag' terminal.o(.text+0x362): undefined reference to `tgetflag' terminal.o(.text+0x3b7): undefined reference to `tgetflag' terminal.o(.text+0x3cb): undefined reference to `tgetflag' /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(terminal.o): In function `ding': terminal.o(.text+0x5c9): undefined reference to `tputs' /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(terminal.o): In function `_rl_bac kspace': terminal.o(.text+0x716): undefined reference to `tputs' /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(terminal.o): In function `_rl_ena ble_meta_key': terminal.o(.text+0x78c): undefined reference to `tputs' /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(terminal.o): In function `_rl_con trol_keypad': terminal.o(.text+0x7b5): undefined reference to `tputs' terminal.o(.text+0x7d5): undefined reference to `tputs' /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(display.o)(.text+0xa69): more und efined references to `tputs' follow /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(display.o): In function `_rl_clea r_screen': display.o(.text+0x1ceb): undefined reference to `tgoto' display.o(.text+0x1cfa): undefined reference to `tputs' display.o(.text+0x1d24): undefined reference to `tputs' display.o(.text+0x1d58): undefined reference to `tgoto' display.o(.text+0x1d68): undefined reference to `tputs' display.o(.text+0x1d9a): undefined reference to `tputs' display.o(.text+0x1dc8): undefined reference to `tputs' display.o(.text+0x1dfb): undefined reference to `tputs' display.o(.text+0x1e23): undefined reference to `tputs' /usr/obj/optimum/src/tmp/usr/lib/libreadline.a(display.o)(.text+0x1f1f): more un defined references to `tputs' follow *** Error code 1 Stop in /optimum/src/gnu/usr.bin/binutils/gdb. *** Error code 1 Stop in /optimum/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /optimum/src. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Sent on 31-Aug-99 at 00:14:36 Powered by FreeBSD -> http://www.freebsd.org <- "The Power to Serve" PGP key available upon request or may be cut at http://members.tripod.com/fbsd/pgpkey.html What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wayward symlink and libncurses
The recent world breakage seems to be due to wayward symlinks. ls -l /usr/obj/usr/src/tmp/usr/lib lrwxr-xr-x 21 Aug 30 12:36 libcurses.a@ -> /usr/lib/libncurses.a lrwxr-xr-x 21 Aug 30 12:36 libmytinfo.a@ -> /usr/lib/libncurses.a -r--r--r-- 377380 Aug 30 12:36 libncurses.a lrwxr-xr-x 21 Aug 30 12:36 libtermcap.a@ -> /usr/lib/libncurses.a lrwxr-xr-x 21 Aug 30 12:36 libtermlib.a@ -> /usr/lib/libncurses.a lrwxr-xr-x 21 Aug 30 12:36 libtinfo.a@ -> /usr/lib/libncurses.a Shouldn't these point at ./libncurses.a? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
Jonathan Lemon <[EMAIL PROTECTED]> wrote: >On Aug 08, 1999 at 03:01:32PM -0700, Julian Elischer wrote: >> I don't want to sound ungrateful, but couldn't we have defined these in >> terms of Usecs and translated? ... > I think that having it in units of usec is >probably better than msec; it provides more in the way of >"forward compatability", Given a 32-bit integer, it also puts a much lower limit on the maximum. This is likely to bite on TCP keep-alives - currently they are set to 2 hours. We can't represent 2 hours as usecs in 32 bits. > and allows for a larger HZ. Not really. The only problem is that the rounding errors get more noticable as the number of units approaches HZ. This is an artifact that should be pointed out in the description - eg if you ask for 2msec on an Alpha, you'll probably get 1.66msec. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
makeworld breakage in gdb
cc -O -pipe -D_GNU_SOURCE -I- -I. -I/usr/src/gnu/usr.bin/binutils/gdb/i386
-I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include
-I/usr/src/gnu/usr.bin/binutils/gdb/i386
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb
-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/config -DFREEBSD_ELF
-I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/obj/usr/src/tmp/usr/include/readline
-DNO_MMALLOC -I/usr/obj/usr/src/tmp/usr/include -static -o gdb init.o annotate.o
ax-general.o ax-gdb.o bcache.o blockframe.o breakpoint.o buildsym.o c-exp.o c-lang.o
c-typeprint.o c-valprint.o ch-exp.o ch-lang.o ch-typeprint.o ch-valprint.o coffread.o
command.o complaints.o copying.o corefile.o corelow.o core-regset.o cp-valprint.o
dcache.o dbxread.o demangle.o dwarfread.o dwarf2read.o elfread.o environ.o eval.o
exec.o expprint.o f-exp.o f-lang.o f-typeprint.o f-valprint.o findvar.o fork-child.o
gdbarch.o gdbtypes.o infcmd.o inflow.o infptrace.o infrun.o inftarg.o language.o
jv-exp.o jv-lang.o jv-valprint.o jv-typeprint.o nlmread.o m2-lang.o m2-exp.o
m2-typeprint.o m2-valprint.o main.o maint.o mdebugread.o mem-break.o minsyms.o
objfiles.o parse.o printcmd.o remote.o remote-utils.o scm-exp.o scm-lang.o
scm-valprint.o solib.o source.o stabsread.o stack.o symfile.o symmisc.o symtab.o
target.o thread.o top.o tracepoint.o typeprint.o utils.o valarith.o valops.o
valprint.o values.o version.o serial.o ser-unix.o ser-tcp.o callback.o freebsd-nat.o
i386-tdep.o i387-tdep.o kvm-fbsd.o -L../libbfd -lbfd -L../libopcodes -lopcodes
-lreadline -lgnuregex -L../libiberty -liberty -ltermcap
utils.o: In function `init_page_info':
utils.o(.text+0xbf0): undefined reference to `tgetent'
utils.o(.text+0xc16): undefined reference to `tgetnum'
utils.o(.text+0xc3c): undefined reference to `tgetnum'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function
`_rl_get_screen_size':
terminal.o(.text+0x78): undefined reference to `tgetnum'
terminal.o(.text+0xc8): undefined reference to `tgetnum'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function
`rl_resize_terminal':
terminal.o(.text+0x1a7): undefined reference to `tgetstr'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function
`_rl_init_terminal_io':
terminal.o(.text+0x25b): undefined reference to `tgetent'
terminal.o(.text+0x3a6): undefined reference to `tgetflag'
terminal.o(.text+0x3b7): undefined reference to `tgetflag'
terminal.o(.text+0x406): undefined reference to `tgetflag'
terminal.o(.text+0x417): undefined reference to `tgetflag'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function `_rl_backspace':
terminal.o(.text+0x612): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function `ding':
terminal.o(.text+0x6c4): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function
`_rl_enable_meta_key':
terminal.o(.text+0x717): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function
`_rl_control_keypad':
terminal.o(.text+0x75f): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(display.o): In function `rl_redisplay':
display.o(.text+0xa99): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(display.o)(.text+0xffb): more undefined
references to `tputs' follow
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(display.o): In function `_rl_clear_screen':
display.o(.text+0x1933): undefined reference to `tgoto'
display.o(.text+0x1940): undefined reference to `tputs'
display.o(.text+0x196c): undefined reference to `tputs'
display.o(.text+0x199e): undefined reference to `tputs'
display.o(.text+0x19d0): undefined reference to `tputs'
display.o(.text+0x1a02): undefined reference to `tgoto'
display.o(.text+0x1a0e): undefined reference to `tputs'
display.o(.text+0x1a3a): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(display.o): In function `_rl_update_final':
display.o(.text+0x1b5a): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(display.o): In function
`_rl_redisplay_after_sigwinch':
display.o(.text+0x1b89): undefined reference to `tputs'
display.o(.text+0x1bb1): undefined reference to `tputs'
/usr/obj/usr/src/tmp/usr/lib/libreadline.a(display.o)(.text+0x1bd5): more undefined
references to `tputs' follow
*** Error code 1
Stop in /usr/src/gnu/usr.bin/binutils/gdb.
*** Error code
1N
'²æìr¸{û Ù[h¨èÚ&£ñkyàRú+û§²æìr¸yúÞy» ýË«éíþ)í
æèw* ¶¦zË
Re: HEADS UP
On Aug 08, 1999 at 11:40:23PM +0200, Mark Murray wrote: > > I've just committed the revised TCP timer code. There are some > > user visible changes: > : > > Also, some new sysctls have been added: > : > ...&c > > Please let the plebs know, in less kernel-ish terms, what this means? If you don't know that they are, you don't need to worry about them. :-) Seriously, they are allow finer control over some of the TCP behavior. delacktime is related to Nagle's algorithm, and specifies how long a system should delay ACK'ing a packet in hopes that it can collect some data from ther user and piggyback it on top of the ACK packet. flightsize indicates how many packets are allowed to be "in flight", normally, the flightsize is limited to 1 packet at the start of each TCP session, doubles for every ACK received. The intent is that the sender doesn't flood the network (and intervening routers) with a burst of packets, but "slow starts" its transmission. This is normally disabled on "local" networks. Some researchers (Zhang, Floyd) have proposed changing the initial flightsize to 3 to get better performance, recognizing that some of the assumptions about the underlying network are not the same now as they were years ago. msl is the "maximum time" a segment can live in a network, and is the amount of time before a socket can be re-used. Many of these are useful only in specialized applications (or benchamrks!), and it's easier to twiddle a few knobs than to re-compile the kernel each time. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Aug 08, 1999 at 03:01:32PM -0700, Julian Elischer wrote: > > > On Mon, 30 Aug 1999, Rodney W. Grimes wrote: > > > > I've just committed the revised TCP timer code. There are some > > > user visible changes: > > > > > > User visible TCP timers are now in units of the system clock > > > (10ms for the i386), not those of the slowtimeout (500ms). So > > > if you have customized one of these values, (e.g.: net.inet.tcp.keepintvl), > > > you'll need to multiply it appropriately to keep the same interval. > > I don't want to sound ungrateful, but couldn't we have defined these in > terms of Usecs and translated? > I mean I sometimes compile hz to be 1000 for some reasons.. > this means that I have to reset all these values in my rc scripts. > > As an example the kern.quantum variable that will always be the same > despite a redefinition of Hz. It's stored internally in terms of Hz but > exported in uSecs. Okay, I'll work on this, and should have a patch by tomorrow (unless somone beats to me it). I think that having it in units of usec is probably better than msec; it provides more in the way of "forward compatability", and allows for a larger HZ. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -I/usr/obj/usr/src/tm p/usr/include -static -o sh alias.o arith.o arith_lex.o cd.o echo.o error.o eva l.o exec.o expand.o histedit.o input.o jobs.o mail.o main.o memalloc.o miscbltin .o mystring.o options.o output.o parser.o printf.o redir.o show.o trap.o var.o b uiltins.o init.o nodes.o syntax.o -ll -ledit -ltermcap /usr/obj/usr/src/tmp/usr/lib/libedit.a(editline.o): In function `el_gets': editline.o(.text+0x5eec): undefined reference to `tgoto' editline.o(.text+0x5ef5): undefined reference to `tputs' editline.o(.text+0x5f2a): undefined reference to `tputs' editline.o(.text+0x607f): undefined reference to `tgoto' editline.o(.text+0x6088): undefined reference to `tputs' editline.o(.text+0x618d): undefined reference to `tgoto' editline.o(.text+0x61b4): undefined reference to `tputs' editline.o(.text+0x61e2): undefined reference to `tputs' editline.o(.text+0x620a): undefined reference to `tputs' editline.o(.text+0x627e): undefined reference to `tgoto' -- Jason DiCioccio | [EMAIL PROTECTED] FreeBSD - The Power to Serve | http://www.freebsd.org | http://www.ods.org -- On Mon, 30 Aug 1999, Jordan K. Hubbard wrote: > > Thats not where it dies :).. > > Be more specific. Just saying "it dies" does not help anyone here. > > - Jordan > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
Systems Administrator wrote: > Thats not where it dies :).. It's the same problem. libtermcap has changed or causes conflicts with symbols (if I understand some of Peter's commits). The tput function you noted would have come from -ltermcap (as does the tgetent, tgetnum, etc.i below) What I don't know is whether -ltermcap is replaced by -lncurses or -ltermcap -lncurses. > > > utils.o(.text+0xbd0): undefined reference to `tgetent' > > utils.o(.text+0xbf6): undefined reference to `tgetnum' > > utils.o(.text+0xc1c): undefined reference to `tgetnum' > > /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function >`_rl_get_screen_size': > > terminal.o(.text+0x79): undefined reference to `tgetnum' > > terminal.o(.text+0xc9): undefined reference to `tgetnum' > > /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function >`rl_resize_terminal': > > terminal.o(.text+0x1ae): undefined reference to `tgetstr' > > > -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
> Thats not where it dies :).. Be more specific. Just saying "it dies" does not help anyone here. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
Thats not where it dies :).. -- Jason DiCioccio | [EMAIL PROTECTED] FreeBSD - The Power to Serve | http://www.freebsd.org | http://www.ods.org -- On Mon, 30 Aug 1999, Steve Kargl wrote: > Matthew N. Dodd wrote: > > On Mon, 30 Aug 1999, Systems Administrator wrote: > > > Make world for 4.0 is failing due to libedit libraries that were > > > compiled during the process.. various errors with tputs and other > > > functions in libedit.a, please commit a fix soon, I just reinstalled > > > -RELEASE and wanna get out of it. > > > > Any chance you could cut and paste the errors? > > > > This is probably caused by the integration of ncurses. > Peter Wemm warned that the tree might be broken for a > day while he/someone chases down the loose ends. > > -- > Steve > > > cc -O2 -pipe -mpentiumpro -D_GNU_SOURCE -I- -I. >-I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb >-I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386 >-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include >-I/usr/src/gnu/usr.bin/binutils/gdb/i386 >-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils >-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd >-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb >-I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/config -DFREEBSD_ELF >-I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/obj/usr/src/tmp/usr/include/readline >-DNO_MMALLOC -I/usr/obj/usr/src/tmp/usr/include -static -o gdb init.o annotate.o >ax-general.o ax-gdb.o bcache.o blockframe.o breakpoint.o buildsym.o c-exp.o c-lang.o >c-typeprint.o c-valprint.o ch-exp.o ch-lang.o ch-typeprint.o ch-valprint.o coffread.o >command.o complaints.o copying.o corefile.o corelow.o core-regset.o cp-valprint.o >dcache.o dbxread.o demangle.o dwarfread.o dwarf2read.o elfread.o environ.o eval.o >exec.o expprint.o f-exp.o f-lang.o f-typeprint.o f-valprint.o findvar.o fork-child.o >gdbarch.o gdbtypes.o infcmd.o inflow.o infptrace.o infrun.o inftarg.o language.o >jv-exp.o jv-lang.o jv-valprint.o jv-typeprint.o nlmread.o m2-lang.o m2-exp.o >m2-typeprint.o m2-valprint.o main.o maint.o mdebugread.o mem-break.o minsyms.o >objfiles.o parse.o printcmd.o remote.o remote-utils.o scm-exp.o scm-lang.o >scm-valprint.o solib.o source.o stabsread.o stack.o symfile.o symmisc.o symtab.o >target.o thread.o top.o tracepoint.o typeprint.o utils.o valarith.o valops.o >valprint.o values.o version.o serial.o ser-unix.o ser-tcp.o callback.o freebsd-nat.o >i386-tdep.o i387-tdep.o kvm-fbsd.o -L../libbfd -lbfd -L../libopcodes -lopcodes >-lreadline -lgnuregex -L../libiberty -liberty -ltermcap > utils.o: In function `init_page_info': > utils.o(.text+0xbd0): undefined reference to `tgetent' > utils.o(.text+0xbf6): undefined reference to `tgetnum' > utils.o(.text+0xc1c): undefined reference to `tgetnum' > /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function >`_rl_get_screen_size': > terminal.o(.text+0x79): undefined reference to `tgetnum' > terminal.o(.text+0xc9): undefined reference to `tgetnum' > /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function >`rl_resize_terminal': > terminal.o(.text+0x1ae): undefined reference to `tgetstr' > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
Matthew N. Dodd wrote: > On Mon, 30 Aug 1999, Systems Administrator wrote: > > Make world for 4.0 is failing due to libedit libraries that were > > compiled during the process.. various errors with tputs and other > > functions in libedit.a, please commit a fix soon, I just reinstalled > > -RELEASE and wanna get out of it. > > Any chance you could cut and paste the errors? > This is probably caused by the integration of ncurses. Peter Wemm warned that the tree might be broken for a day while he/someone chases down the loose ends. -- Steve cc -O2 -pipe -mpentiumpro -D_GNU_SOURCE -I- -I. -I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/config -DFREEBSD_ELF -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/obj/usr/src/tmp/usr/include/readline -DNO_MMALLOC -I/usr/obj/usr/src/tmp/usr/include -static -o gdb init.o annotate.o ax-general.o ax-gdb.o bcache.o blockframe.o breakpoint.o buildsym.o c-exp.o c-lang.o c-typeprint.o c-valprint.o ch-exp.o ch-lang.o ch-typeprint.o ch-valprint.o coffread.o command.o complaints.o copying.o corefile.o corelow.o core-regset.o cp-valprint.o dcache.o dbxread.o demangle.o dwarfread.o dwarf2read.o elfread.o environ.o eval.o exec.o expprint.o f-exp.o f-lang.o f-typeprint.o f-valprint.o findvar.o fork-child.o gdbarch.o gdbtypes.o infcmd.o inflow.o infptrace.o infrun.o inftarg.o language.o jv-exp.o jv-lang.o jv-valprint.o jv-typeprint.o nlmread.o m2-lang.o m2-exp.o m2-typeprint.o m2-valprint.o main.o maint.o mdebugread.o mem-break.o minsyms.o objfiles.o parse.o printcmd.o remote.o remote-utils.o scm-exp.o scm-lang.o scm-valprint.o solib.o source.o stabsread.o stack.o symfile.o symmisc.o symtab.o target.o thread.o top.o tracepoint.o typeprint.o utils.o valarith.o valops.o valprint.o values.o version.o serial.o ser-unix.o ser-tcp.o callback.o freebsd-nat.o i386-tdep.o i387-tdep.o kvm-fbsd.o -L../libbfd -lbfd -L../libopcodes -lopcodes -lreadline -lgnuregex -L../libiberty -liberty -ltermcap utils.o: In function `init_page_info': utils.o(.text+0xbd0): undefined reference to `tgetent' utils.o(.text+0xbf6): undefined reference to `tgetnum' utils.o(.text+0xc1c): undefined reference to `tgetnum' /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function `_rl_get_screen_size': terminal.o(.text+0x79): undefined reference to `tgetnum' terminal.o(.text+0xc9): undefined reference to `tgetnum' /usr/obj/usr/src/tmp/usr/lib/libreadline.a(terminal.o): In function `rl_resize_terminal': terminal.o(.text+0x1ae): undefined reference to `tgetstr' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Mon, 30 Aug 1999, Jonathan Lemon wrote: > On Aug 08, 1999 at 11:36:30PM +0200, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Jonathan Lemon writes: > > > I've just committed the revised TCP timer code. There are some > > >user visible changes: > > > > > > User visible TCP timers are now in units of the system clock > > > (10ms for the i386) > > > > Please, can we have them be in milliseconds ? > Wouldn't this mean writing a sysctl proc for each variable, > instead of directly changing the underlying integer? I did > consider this, but wasn't sure if it would be worth the effort. and? you already indicated that setting the value to 0 might be bad. having a generic Usec to Tics handler might be usable if it can also protect against 0 values.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World failure
On Mon, 30 Aug 1999, Systems Administrator wrote: > Make world for 4.0 is failing due to libedit libraries that were > compiled during the process.. various errors with tputs and other > functions in libedit.a, please commit a fix soon, I just reinstalled > -RELEASE and wanna get out of it. Any chance you could cut and paste the errors? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the latest changes to ifconfig (I guess) -> Bad guess...
Sorry to reply to my own mail -- never report problems before investigating what was committed. The $Id$ -> $FreeBSD$ changes to ifconfig are probably not the cause -- more likely the changes to xl (1.52 -> 1.53), and the addition of the mii-controller. Anybody else seeing this, or should I look somewhere else alltogether? > Hi, > > After the recent changes to ifconfig and the xl driver I am getting > a panic when rc.network runs ifconfig: > > [...] > Doing initial network setup: hostname. > UP,LOOPBACK,RUNN > ING,MULTICAST> m > E®WioFnetmask 0xffa00 > tal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x0 > stack pointer = 0x10:0xc8d18dc4 > frame pointer = 0x10:0xc8d18ddc > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 78 (ifconfig) > interrupt mask = net > kernel: type 12 trap, code=0 > Stopped at 0: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc020cac4 > stack pointer = 0x10:0xc8d18c3c > frame pointer = 0x10:0xc8d18c40 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 78 (ifconfig) > interrupt mask = net > kernel: type 12 trap, code=0 > db> > > This is after a make buildworld/installworld on -current (as of today). > > dmesg and config-file: > > > FreeBSD/i386 bootstrap loader, Revision 0.7 639/65472kB > ([EMAIL PROTECTED], Mon Aug 30 10:58:22 CEST 1999) > /kernel text=0x164b84 data=0x1ee6c+0x1e1e8 > syms=[0x4+0x24760+0x4+0x268f8] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [kernel]... > Copyright (c) 1992-1999 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights > reserved. > FreeBSD 4.0-CURRENT #0: Mon Aug 30 18:56:22 CEST 1999 > [EMAIL PROTECTED]:/usr/src/sys/compile/HOME > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium II/Xeon/Celeron (400.90-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x652 Stepping = 2 > > >Features=0x183f9ff > real memory = 134217728 (131072K bytes) > avail memory = 127102976 (124124K bytes) > Preloaded elf kernel "kernel" at 0xc02ef000. > VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc029d042 (122) > VESA: ATI MACH64 > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > apm0: on motherboard > apm: found APM BIOS v1.2, connected at v1.2 > pcib0: on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on > pci0 > pci1: on pcib1 > vga-pci0: irq 15 at device 0.0 on > pci1 > isab0: at device 7.0 on pci0 > isa0: on isab0 > chip1: at device 7.1 on pci0 > chip2: at device 7.2 on pci0 > chip3: at device 7.3 on pci0 > ahc0: irq 15 at device 15.0 on pci0 > ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs > pcm0: irq 11 at device 16.0 on pci0 > pcm0: using I/O space register mapping at 0xe800 > xl0: <3Com 3c905B-TX Fast Etherlink XL> irq 10 at device 18.0 on pci0 > xl0: Ethernet address: 00:10:4b:7a:96:7d > miibus0: on xl0 > xlphy0: <3Com internal media interface> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xlphy1: <3Com internal media interface> on miibus0 > xlphy1: ignoring this PHY, non-zero instance > device_probe_and_attach: xlphy1 attach returned 6 > Probing for PnP devices: > atkbdc0: at port 0x60-0x6f on isa0 > atkbd0: irq 1 on atkbdc0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3b0-0x3df iomem 0xa-0xb on > isa0 > sc0: on isa0 > sc0: VGA <9 virtual consoles, flags=0x0> > fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A, console > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0 at port 0x378-0x37f on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > lpt0: on ppbus 0 > Waiting 5 seconds for SCSI devices to settle > changing root device to da0s1a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 10.000MB/s transfers (10.000MHz, offset 15) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > da2 at ahc0 bus 0 target 8 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) > da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) > da1
Re: HEADS UP
On Mon, 30 Aug 1999, Rodney W. Grimes wrote: > > I've just committed the revised TCP timer code. There are some > > user visible changes: > > > > User visible TCP timers are now in units of the system clock > > (10ms for the i386), not those of the slowtimeout (500ms). So > > if you have customized one of these values, (e.g.: net.inet.tcp.keepintvl), > > you'll need to multiply it appropriately to keep the same interval. I don't want to sound ungrateful, but couldn't we have defined these in terms of Usecs and translated? I mean I sometimes compile hz to be 1000 for some reasons.. this means that I have to reset all these values in my rc scripts. As an example the kern.quantum variable that will always be the same despite a redefinition of Hz. It's stored internally in terms of Hz but exported in uSecs. > > > > Also, some new sysctls have been added: > > I didn't think I would ever see this!! Good job, hats off to you and > assoctiates! > > > > > net.inet.tcp.delacktime: 20 > > Specifies the timeout for delayed acks (200ms). > > net.inet.tcp.slowstart_flightsize: 1 > > Specifies how many packets are included in the initial > > slow-start flight. Setting this value to 0 will probably > > result in a non-working system. Choosing a high value > > would be considered antisocial. > > net.inet.tcp.local_slowstart_flightsize: 65535 > > Same as above, but only applies to slowstart on "local" > > networks. Note that the flightsize is constrained by > > the receiver's advertised window size. > > One question though, how is ``local'' defined? > > > -- > Rod Grimes - KD7CAX - (RWG25)[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
Make World failure
Make world for 4.0 is failing due to libedit libraries that were compiled during the process.. various errors with tputs and other functions in libedit.a, please commit a fix soon, I just reinstalled -RELEASE and wanna get out of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
In message <[EMAIL PROTECTED]>, Jonathan Lemon writes: >On Aug 08, 1999 at 11:36:30PM +0200, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Jonathan Lemon writes: >> > I've just committed the revised TCP timer code. There are some >> >user visible changes: >> > >> > User visible TCP timers are now in units of the system clock >> > (10ms for the i386) >> >> Please, can we have them be in milliseconds ? > >Wouldn't this mean writing a sysctl proc for each variable, >instead of directly changing the underlying integer? I did >consider this, but wasn't sure if it would be worth the effort. Yes, you'd have to, but considering that HZ is 1024 on alpha and 100 on i386 I think it is well worth the effort... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Aug 08, 1999 at 11:36:30PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jonathan Lemon writes: > > I've just committed the revised TCP timer code. There are some > >user visible changes: > > > > User visible TCP timers are now in units of the system clock > > (10ms for the i386) > > Please, can we have them be in milliseconds ? Wouldn't this mean writing a sysctl proc for each variable, instead of directly changing the underlying integer? I did consider this, but wasn't sure if it would be worth the effort. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
> I've just committed the revised TCP timer code. There are some > user visible changes: : > Also, some new sysctls have been added: : ...&c Please let the plebs know, in less kernel-ish terms, what this means? Thanks! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
In message <[EMAIL PROTECTED]>, Jonathan Lemon writes: > I've just committed the revised TCP timer code. There are some >user visible changes: > > User visible TCP timers are now in units of the system clock > (10ms for the i386) Please, can we have them be in milliseconds ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
On Aug 08, 1999 at 02:27:53PM -0700, Rodney W. Grimes wrote: > > I've just committed the revised TCP timer code. There are some > > user visible changes: > > > > User visible TCP timers are now in units of the system clock > > (10ms for the i386), not those of the slowtimeout (500ms). So > > if you have customized one of these values, (e.g.: net.inet.tcp.keepintvl), > > you'll need to multiply it appropriately to keep the same interval. > > > > Also, some new sysctls have been added: > > I didn't think I would ever see this!! Good job, hats off to you and > assoctiates! > > > > > net.inet.tcp.delacktime: 20 > > Specifies the timeout for delayed acks (200ms). > > net.inet.tcp.slowstart_flightsize: 1 > > Specifies how many packets are included in the initial > > slow-start flight. Setting this value to 0 will probably > > result in a non-working system. Choosing a high value > > would be considered antisocial. > > net.inet.tcp.local_slowstart_flightsize: 65535 > > Same as above, but only applies to slowstart on "local" > > networks. Note that the flightsize is constrained by > > the receiver's advertised window size. > > One question though, how is ``local'' defined? The same way as it has been; in_localaddr(). Basically, if the machine is on the same network, (or subnet, depending on the net.inet.ip.subnets_are_local setting). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
> I've just committed the revised TCP timer code. There are some > user visible changes: > > User visible TCP timers are now in units of the system clock > (10ms for the i386), not those of the slowtimeout (500ms). So > if you have customized one of these values, (e.g.: net.inet.tcp.keepintvl), > you'll need to multiply it appropriately to keep the same interval. > > Also, some new sysctls have been added: I didn't think I would ever see this!! Good job, hats off to you and assoctiates! > > net.inet.tcp.delacktime: 20 > Specifies the timeout for delayed acks (200ms). > net.inet.tcp.slowstart_flightsize: 1 > Specifies how many packets are included in the initial > slow-start flight. Setting this value to 0 will probably > result in a non-working system. Choosing a high value > would be considered antisocial. > net.inet.tcp.local_slowstart_flightsize: 65535 > Same as above, but only applies to slowstart on "local" > networks. Note that the flightsize is constrained by > the receiver's advertised window size. One question though, how is ``local'' defined? -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP
I've just committed the revised TCP timer code. There are some user visible changes: User visible TCP timers are now in units of the system clock (10ms for the i386), not those of the slowtimeout (500ms). So if you have customized one of these values, (e.g.: net.inet.tcp.keepintvl), you'll need to multiply it appropriately to keep the same interval. Also, some new sysctls have been added: net.inet.tcp.delacktime: 20 Specifies the timeout for delayed acks (200ms). net.inet.tcp.slowstart_flightsize: 1 Specifies how many packets are included in the initial slow-start flight. Setting this value to 0 will probably result in a non-working system. Choosing a high value would be considered antisocial. net.inet.tcp.local_slowstart_flightsize: 65535 Same as above, but only applies to slowstart on "local" networks. Note that the flightsize is constrained by the receiver's advertised window size. net.inet.tcp.msl: 3000 Specifies the "Maximum Segment Lifetime", 30sec. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-CURRENT SMP crash with vinum raid-5 and softupdates
On Mon, Aug 30, 1999 at 09:14:11AM +0200, Bernd Walter wrote: > On Mon, Aug 30, 1999 at 03:58:16PM +0930, Greg Lehey wrote: > > > > Yes, this is the same thing. Until Parag came along, I was beginning > > to think it was a problem with your hardware :-( > Yes - I would have done tests with a host at work to check if it's reproduceable > with another hardware - now I think this is obsolete. > It would be difficult to give you login to that host and a host for gdb > anyway. The host at work paniced too. It's a dual CPU PIII system - but I hadn't DDB and everthing else needed compiled in. > > > > Is there any way for me to look at this? Do you have an IDE disk on > > your machine that you could dump to? > Will it write a dump to ide? I have only one ide cd-rom in that host, but I > have an unused 130M IDE-HDD. OK I set up the 130M drive configured it as dumpdev and used your patches. One patch did not compile - I wrote you in a different mail. After some time of waiting I got a panic and tried to dump - but it did not work. dumping hang after syncing the drives - is there a way to directly initiate the dump without syncing? I will reproduce the panic and leave it there, so that you can check with kgdb. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with the latest changes to ifconfig (I guess)
Hi, After the recent changes to ifconfig and the xl driver I am getting a panic when rc.network runs ifconfig: [...] Doing initial network setup: hostname. UP,LOOPBACK,RUNN ING,MULTICAST> m E®WioFnetmask 0xffa00 tal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xc8d18dc4 frame pointer = 0x10:0xc8d18ddc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 78 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 Stopped at 0: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc020cac4 stack pointer = 0x10:0xc8d18c3c frame pointer = 0x10:0xc8d18c40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 78 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 db> This is after a make buildworld/installworld on -current (as of today). dmesg and config-file: FreeBSD/i386 bootstrap loader, Revision 0.7 639/65472kB ([EMAIL PROTECTED], Mon Aug 30 10:58:22 CEST 1999) /kernel text=0x164b84 data=0x1ee6c+0x1e1e8 syms=[0x4+0x24760+0x4+0x268f8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Mon Aug 30 18:56:22 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/HOME Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (400.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134217728 (131072K bytes) avail memory = 127102976 (124124K bytes) Preloaded elf kernel "kernel" at 0xc02ef000. VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc029d042 (122) VESA: ATI MACH64 Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 15 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 chip1: at device 7.1 on pci0 chip2: at device 7.2 on pci0 chip3: at device 7.3 on pci0 ahc0: irq 15 at device 15.0 on pci0 ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs pcm0: irq 11 at device 16.0 on pci0 pcm0: using I/O space register mapping at 0xe800 xl0: <3Com 3c905B-TX Fast Etherlink XL> irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:10:4b:7a:96:7d miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xlphy1: <3Com internal media interface> on miibus0 xlphy1: ignoring this PHY, non-zero instance device_probe_and_attach: xlphy1 attach returned 6 Probing for PnP devices: atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <9 virtual consoles, flags=0x0> fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus 0 Waiting 5 seconds for SCSI devices to settle changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da2 at ahc0 bus 0 target 8 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: / was not properly dismounted vinum: loaded Can't open history file /var/tmp/vinum_history: Read-only file system (30) vinum: reading configuration from /dev/da2s1h vinum: updatin
Re: NFS-related panic on SMP
:Hi, : :With a kernel built from -current cvsup'd at Sun Aug 22 04:03:19 BST 1999, :I got the following panic doing make -j8 world with /usr/src via NFS and :/usr/obj local: : :Panic: free vnode isn't :mp_lock = 0001; cpuid = 0; lapic.id = : :backtrace (hand-transcribed): : :panic :getnewvnode() + 0x157 :nfs_nget() + 0x107 :nfs_lookup()+0xe8d :lookup() + 0x2ab :namei() + 0x137 :stat() + 0x44 :syscall() + 0x186 :Xint0x80_syscall() + 0x31 : :Any ideas? :-- :Bob Bishop (0118) 977 4017 international code +44 118 :[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK This is the second person with a crash in nfs_lookup. No major changes have been made to NFS yet -- my patch set is still uncommitted. I can only conclude that something else someone has done has broken something. With my patchset and the latest current, I am able to do buildworlds in a loop forever on an SMP box using precisely that setup: /usr/src via NFS, /usr/obj local (and also /usr/obj/ via VN). At this instant my patch set will not patch cleanly due to some inappropriate commits made last night which I am trying to resolve. (However, these commits are probably not responsible for this particular problem since you indicate an early sunday morning image). I recommend waiting a few days, hopefully this mess will be straightened out by then and we can put everyone on the same page again. I can't update my patch until the mess that was committed last night has been backed out. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS-related panic on SMP
Hi, With a kernel built from -current cvsup'd at Sun Aug 22 04:03:19 BST 1999, I got the following panic doing make -j8 world with /usr/src via NFS and /usr/obj local: Panic: free vnode isn't mp_lock = 0001; cpuid = 0; lapic.id = backtrace (hand-transcribed): panic getnewvnode() + 0x157 nfs_nget() + 0x107 nfs_lookup()+0xe8d lookup() + 0x2ab namei() + 0x137 stat() + 0x44 syscall() + 0x186 Xint0x80_syscall() + 0x31 Any ideas? -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
> Rodney W. Grimes writes:
>
> >What verion of the cvs binary are you running (cvs -v)?
>
> Concurrent Versions System (CVS) 1.10 `Halibut' (client/server)
>
> >Are you getting a copy of CVSROOT?
>
> yes...as part of src-all, but it's not used as *my* CVSROOT.
What is the content of *your* CVSROOT/options file?
> Let's go back to the beginning here. Is my cvs responsible for
> expanding the $FreeBSD$ tags, or are they supposed to arrive in my cvs
> repository already expanded?
Your cvs is responsible for expanding the $FreeBSD$ tag when it needs
expanded.
> If my cvs needs to do it, then I presume
> I need to add some options to my CVSROOT to make that happen. If so,
> is there a description somewhere of what I need to steal out of
> FreeBSD's CVSROOT that will make it happen?
The file CVSROOT/options should contain:
gndrsh:root {743}# cat options
tag=FreeBSD=CVSHeader
tagexpand=iFreeBSD,Id
gndrsh:root {744}#
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Weird new SCSI diagnostics in -current
>I'm noticing some new output. What does it mean and is it going >to stay there? :-) Peter killed these last week. > >- Jordan -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI surprise! (was: Softupdates reliability?)
As Stephen McKay wrote ... > I took the lid off anyway hoping to find anything at all weird and noticed > something I had forgotten. I was using a Seagate ST51080N 1GB disk earlier > for some experimenting and had disconnected the POWER, but not the SCSI CABLE. > (It's a really noisy drive!) When I also unplugged the SCSI cable, all crashes > stopped. I've now used the machine intensively for several days (copying over > 20GB of small and big files, and read and written several tapes) without > incident. Conclusions: > > 4) My stepping of K6-2/300 is just fine > 5) My Exabyte really is ok :-) > 6) It is NOT safe to have a powered down SCSI device attached to a SCSI chain > 7) The world really is a wonderful place ;-) > > So, apart from being happy at having stable hardware again, I am intensely > curious about this. Why is a powered down SCSI device so nasty? For example, It is normally not so nasty. Did this particular device have the SCSI terminator? If so, the terminator needs +5V (terminator power aka TERMPWR) to function correctly. Some devices can be setup to take terminator power from the bus (generally supplied by the host adapter) or from the device they are installed on. I've run things with power-ed down devices without any ill effects. But always with external terminators, so not with the terminator on the device itself but on the bus cable. > the first crash locked up my SCSI card so that reset didn't fix it, and the > second crash hung one of my disks so that it had to be powered down to even > be recognised! Is there a standard for this stuff? Yes, the ANSI SCSI standard. www.t10.org (.com??) Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
spec_getpages: I/O read failure
.. I hope this is going to the right list .. With 4.0-19990826-CURRENT and 4.0-19990827-CURRENT, been having a bit of a problem that only shows itself once swap starts being used: - Aug 26 19:24:31 zed /kernel: spec_getpages: I/O read failure: (error code=0) bp 0xce0e68f8 vp 0xda84de40 Aug 26 19:24:31 zed /kernel: size: 0, resid: 0, a_count: 32217, valid: 0x0 Aug 26 19:24:31 zed /kernel: nread: 0, reqpage: 7, pindex: 63, pcount: 8 Aug 26 19:24:31 zed /kernel: vm_fault: pager read error, pid 34675 (nntpcached) Aug 26 19:24:31 zed nntpcache-client[34675]: nntpcache.c:291:No such file or directory: SIGSEGV! Aug 26 19:25:02 zed /kernel: spec_getpages: I/O read failure: (error code=0) bp 0xce0e7d78 vp 0xda84de40 Aug 26 19:25:02 zed /kernel: size: 0, resid: 0, a_count: 32472, valid: 0x0 Aug 26 19:25:02 zed /kernel: nread: 0, reqpage: 7, pindex: 219, pcount: 8 Aug 26 19:25:02 zed /kernel: vm_fault: pager read error, pid 36321 (nntpcached) Aug 26 19:25:02 zed nntpcache-client[36321]: nntpcache.c:291: SIGSEGV! - Exact same hardware, w/ 4.0-19990813-CURRENT, and everything works just fine. Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build fail- /pci/if_xl.c:133: miibus_if.h: No such file or directory
Of all the gin joints in all the towns in all the world, FreeBSD mailing list had to walk into mine and say: > Subject says it all. No, the subject does not say it all: the subject says nothing about how you forgot to update your kernel config file to include: controller miibus0 The subject also fails to mention that you didn't go back and read previous postings on this list, especially the one where I said that I had converted the xl driver to use miibus. Of course, nowdays you don't even need to include the xl driver in your kernel. You can just do: kldload mii kldload xl Or you can include the following in /boot/loader.conf and reboot: mii_load="YES" xl_load="YES" -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
> The client system -- A FreeBSD > client system - has a buffer cache. The buffer cache holds an abstraction > for both files and directories. Well, the discussion is about FreeBSD NFS server, not about FreeBSD NFS client. Neither FreeBSD server cannot assume FreeBSD client, nor FreeBSD client can assume FreeBSD server. The NFS server is a simple thing that just do what the client requested, for example read the directory. Bugs in the FreeBSD NFS client is completely different story. > > Our NFS implementation on the client caches the NFS directory via the > buffer cache. It translates the cookies returned by the server to > a block number and offset as cached in the client's buffer cache. > > See nfs_readdirrpc() in sys/nfs/nfs_vnops.c > > This creates a directory-block abstraction on the client. The 'cookies' > the client returns to processes are based on this abstraction and do not > match the cookies returned by the server. > > The problem that we have is that our buffer cache abstraction essentially > fits a variable number of directory entries returned from the server. If > a file is created or deleted on the server, our buffer cache abstraction > gets thrown for a loop. The client _cannot_ depend on that if a file is created or removed on the server, the "bad cookie" error is returned in next readdir. RFC1813 does not require it in any way. > > In order to maintain consistency within the set of cached pages (note: > I'm not talking about cache coherency with the server here, just > consistency within the buffer cache on the client), our buffer cache > abstraction is currently dependant on the verifier key changing on the > server. I don't why it was done this way -- perhaps mtime was found to > not be sufficient. Maybe because it doesn't have sufficient resolution > under NFSv2. Under NFSv3 it should theoretically have sufficient > resolution but how many servers do you know keep the nanoseconds field > updated? I don't believe in it. First of all, NFSv2 has no verifiers, and work reasonably well. (There is a belief that NFSv2 is much more reliable than NFSv3, you know.) Then, invalidation of cached data is heavily depended on mtime anyway. The client don't do readdir RPC if it think that its cache is valid, it only verify the mtime. Finally, -current has a debugging printf in "bad cookie" handling code for about 4 months, and noone complain that his logs filled with the message. I think I now understand why the "bad cookie" handling code don't do the right thing. Removing files in the directory effectively shift its content to the left. So, if you read the directory and remove files in the same time, you will miss some entries. > When applied to files, the use of mtime to determine when to flush the > cache is nothing more then an inconvenience. But the use of mtime to > determine when to flush a directory cache can be fatal. I still don't see why. > If you want to change the way our directory verifier works, you have to > completely rewrite the directory caching code for the client. I think > you can argue that the verifier is not being implemented properly, but > I'm not going to let anyone change it unless the directory caching code > on the client is rewritten at the same time to use the server's cookies > directly. Really? > Right now the server's cookies are only used by the client to demark > client-buffer-cache buffer boundries. The actual cookies returned to > the *process* running on the client are translated from the client's > buffer cache abstraction of the NFS directory. > > The change that would have to be made would be for the server's cookies > to be passed through all the way to the process sitting on the client > rather then translated in the buffer cache. Then cache consistency in > our client would then not be as sensitive to the varying amounts of > information the server sends us and we could safely leave the verifier > alone on the server. This would require us to change the abstraction our > client uses significantly -- it would not longer be able to use the > cookies passed to it by the user process as direct offsets into the > client's buffer cache. Hmm. I don't think such a big changes in the directory caching is necessary at all, though I didn't actually think about it. Anyway, the verifiers only add to the breakage (see above). Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SCSI surprise! (was: Softupdates reliability?)
[I'm trying my first crosspost experiment here. Please follow up to -scsi.] A week ago I posted my strange crash and subsequent doubts about the proper functioning of softupdates. This is more of the story. I examined the lost+found directory more closely and of the few files that I traced, they were all temporary files or newly created directories (ports actually) created in the CTM update process. So, maybe I didn't really lose anything. Maybe fsck just doesn't recognise one of the safe-but-crashed modes you get when using softupdates. But unfortunately, I needed a CVS tree urgently and restored a backup. To make up for this, I promise to do serious destruction testing of softupdates soon. But, I had another crash almost as soon as I started using the machine again. Again, the Exabyte was being used (but only rewinding at the time), but the obvious trigger this time was intense disk activity (from "rm"). The active file system was not using softupdates, and had a number of fsck -p correctable errors on reboot. Conclusions: 1) The Exabyte was not to blame for the crash 2) The crash wasn't a "scribble junk" crash (first one probably wasn't either) 3) Regular mounts are still safer than softupdates I took the lid off anyway hoping to find anything at all weird and noticed something I had forgotten. I was using a Seagate ST51080N 1GB disk earlier for some experimenting and had disconnected the POWER, but not the SCSI CABLE. (It's a really noisy drive!) When I also unplugged the SCSI cable, all crashes stopped. I've now used the machine intensively for several days (copying over 20GB of small and big files, and read and written several tapes) without incident. Conclusions: 4) My stepping of K6-2/300 is just fine 5) My Exabyte really is ok :-) 6) It is NOT safe to have a powered down SCSI device attached to a SCSI chain 7) The world really is a wonderful place ;-) So, apart from being happy at having stable hardware again, I am intensely curious about this. Why is a powered down SCSI device so nasty? For example, the first crash locked up my SCSI card so that reset didn't fix it, and the second crash hung one of my disks so that it had to be powered down to even be recognised! Is there a standard for this stuff? Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: early panics broken
> panic() no longer works when called early. E.g., after booting with -d, > typing `panic' at the debugger prompt produces no output and > hangs. > > This may be because panic() now depends on uninitialized event handlers. That would only be an issue if panic() then calls boot() without initialising it. Until boot() has been told how to restart the particular hardware it's running on in an appropriate fashion, it's somewhat difficult to do this "right". Perhaps exit() needs to be implemented? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
