Re: exclusive sleep mutex netisr...
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I see several instances of this in /var/log/messages after cvsup'ing Monday evening and rebuilding world and kernel. I haven't seen any messages about this, so I figured I'd ask here. Message: Mar 11 17:33:30 lorne kernel: malloc() of 64 with the following non-sleepablelocks held: Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 Can anybody supply me a clue as to what's going on here? It can be ignored for now, the code path is still under the Giant lock, so this is harmless, I'll fix this soon to use a different approach; the lock was intended to protect against reentrancy. However, I'd be interested to know what is calling malloc(), if that information is in the syslog. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How does a module decide what to support?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: From my observations (yes, please correct me if I am wrong), that modules define what to support in their respective makefiles in the form of SRC= aaa.c bbb.c opt_*.h Where opt_*.h are automagically generated if they are not in machine@ (and the generated files are just empty files that indicate that the kernel file does not specify this option), else they are linked from [EMAIL PROTECTED] If some makefile list SRC= a.c b.c opt_inet.h opt_inet6.h and kernel config lists 'option INET' *only*, then opt_inet.h has '#define INET 1' in it and opt_inet6.h is empty. Is this correct? Yes, I believe so. This is why module makefiles should explicitly create the opt_* files with the #define set, so the module supports all options. See the recent commits I did to the if_tun module, for example (thanks for pointing it out). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/net if_arcsubr.c if_atmsubr.c if_ef.c if_ethersubr.c if_faith.c if_fddisubr.c if_gif.c if_iso88025subr.c if_loop.c if_ppp.c if_sl.c if_spppsubr.c if_stf.c if_tun.c netisr.c netisr.h src/sys/netatalk aarp.c at_extern.h at_var.h ...
On Sat, Mar 08, 2003 at 06:11:35PM +0900, [EMAIL PROTECTED] wrote: Hello. On Tue, Mar 04, 2003 at 03:19:55PM -0800, Jonathan Lemon wrote: jlemon 2003/03/04 15:19:55 PST FreeBSD src repository Modified files: sys/net if_arcsubr.c if_atmsubr.c if_ef.c if_ethersubr.c if_faith.c if_fddisubr.c if_gif.c if_iso88025subr.c if_loop.c if_ppp.c if_sl.c if_spppsubr.c if_stf.c if_tun.c netisr.c netisr.h [snip] After this commit, netgraph seems to be broken. Please Fix (TM:). I'm using mpd(ports/net/mpd) to speak PPPoE for my ADSL connection, and mpd relies on netgraph devices. Oops. This should be fixed now. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Petri Helenius wrote: There's probably a tightloop of frees going on somewhere. It's tough for me to analyze this as I cannot reproduce it. Have you tried running your tests over loopback to see if the same thing happens? What is the definition of tightloop? The received packet mbufs are freed when the packets get processed/discarded which happens once for a packet. The received packet rate is 5-15 packets per second. If so, and it does, can you please explain how to exactly replicate the test? Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable promisc and monitor so it drops the packets after interrupt processing. The overhead beyond that is neglible compared to mb_free. Ah. You are receiver livelocked. Try enabling polling; it will help up to the first stall barrier (NETISR not getting a chance to run protocol processing to completion because of interrupt overhead); there are two other stall barriers after that, and another in user space is possible depending on whether the application layer is request/response. Actually, in -current, we now have a sysctl (net.isr.enable) that will switch the netisr from queuing into a direct dispatch mechanism. In other words, the packet is pushed all the way through the TCP stack to the socket buffer by the network card's interrupt. You can toggle it on and off at runtime, so you can play with it and see if there is any difference. My initial performance tests showed it to be a wash, but ttcp testing today shows it gives a 30% performance boost when run over a gigabit link. YMMV, I guess. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: witness: nfs buf queue
On Thu, Mar 06, 2003 at 01:01:49PM -0500, John Baldwin wrote: On 06-Mar-2003 Jonathan Lemon wrote: Doing a kernel build over NFS on today's -current gives a pile of following error messages during the final link phase: Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 ... Witness didn't used to complain about these until my recent commits, so these could be old bugs that we are just now seeing. It does look like all the lock functions in inmem() use LK_NOWAIT which is exempted from the witness check: if ((flags (LK_NOWAIT|LK_RELEASE)) == 0) WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, lkp-lk_interlock-mtx_object, Acquiring lockmgr lock \%s\, lkp-lk_wmesg); A stack trace from one of these would be helpful. Here you go. This is from -current as of roughly an hour ago, I managed to break into ddb in the middle of witness_warn: kvprintf(c03918eb,c0210c20,e4050bfc,a,e4050c48) at kvprintf+0x8d vprintf(c03918eb,e4050c48,0,c0428620,10001) at vprintf+0x57 witness_warn(5,c0400da8,c03918eb,c039fff9,c6a752d0) at witness_warn+0xbe lockmgr(ca438304,10001,ca438248,c6a752d0,12) at lockmgr+0xc8 vop_sharedlock(e4050c98,0,c039a8b0,35c,c01eb1f2) at vop_sharedlock+0x7d vn_lock(ca438248,12,c6a752d0,83b,c04285e0) at vn_lock+0xeb flushbufqueues(c04285e0,0,c0398a32,104,64) at flushbufqueues+0x100 buf_daemon(0,e4050d48,c0390fdb,35f,0) at buf_daemon+0xd5 fork_exit(c0239920,0,e4050d48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xe4050d7c, ebp = 0 --- No gdb stack trace, my dump device is too small. :-( -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
witness: nfs buf queue
Doing a kernel build over NFS on today's -current gives a pile of following error messages during the final link phase: Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 ... -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: TCP is still broken
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: This program, based on one from the Apache 2 configure script, still causes -current to lock up solid despite the recent bug fixes to the tcptw code. Explicitly closing connected_s before returning from main() seems to avoid the problem. Thanks for the test case. I've just committed a fix for this to -current. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic while on mid-load network traffic
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I first noticed this last night, after recompiling the kernel to fix the delayed ACKs bug. What happens is that if I only use the network regularly (fetchmail/web browsing/IRC/IM/etc), the system seemed to run normally. But after launching a gnutella client, the system panics with the following message on the console (the first 3 times it occurred I was running gtk-gnutella, so I thought it could be either gtk-gnutella- or X-related and tried with mutella on the console with the same result): Do you have revision 1.196 of netinet/tcp_input.c? If not, please re-cvsup, as this version has some fixes that might apply in your case. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic while on mid-load network traffic
On Mon, Feb 24, 2003 at 12:43:43PM -0300, Fred Souza wrote: Do you have revision 1.196 of netinet/tcp_input.c? If not, please re-cvsup, as this version has some fixes that might apply in your case. I just re-cvsup'd and rebuilt the kernel. Same results, except that it now pagefaults quicker. Make sure you have DDB in your kernel (options DDB), then when the box panics, get the panic string and a stack backtrace via db t. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Checksum offload support for Intel 82550/82551
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: The bulk of the changes are in if_fxp.c and if_fxpreg.h. I've been testing this on 5.0-RELEASE, using 82557, 82559 and 82550 cards, and so far it seems to behave as expected. I would like to commit this, but first I want to make sure I'm not stepping on anyone's toes by doing so. I don't know who (if anyone) is maintaining the fxp driver at this point. (I think jlemon was doing, but don't know if he still is.) Tag! You're it! :-) Commit away. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: network stalls in top of the tree current
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: /me too. Try sysctl net.inet.tcp.delayed_ack=0. I suspect that commit: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=678980+0+current/cvs-src Yes, it looks like I screwed up. Turn off delayed_acks until get a fix (being tested) into the tree. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Polygraph Considered Evil 8^) (was: Re: 5-STABLE Roadmap)
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Alex Rousskov wrote: One issue I have with Polygraph is that it intentionally works for a very long time to get worst case performance out of caches; basically, it cache-busts on purpose. Then the test runs. This seems to be an editorial comment on end-to-end guarantees, much more than it seems a valid measurement of actual cache performance. This is a realistic scenario; in the real-world, caches never start empty, but are constantly full. However, polygraph numbers are biased towards misses, and don't quite reflect real-world traffic. net.inet.tcp.msl=3000 And this seems designed to get a bad one. You are aware that, by default, NT systems cheat on the MSL, right? For gigabit, this is a larger number than you want, I think. Polygraph checks the MSL of the target system and complains if it is 3sec (TCP spec violation). Also, the tuning above is for the polygraph *client* machine, not the cache machine under test. One of our kernel patches optimizes handling of 1000s of IP aliases per FreeBSD box. The patch is required for older 4.x kernels to perform at decent levels. IIRC, the patch does not work for recent kernels, probably because of the SYN cache changes. I do not know whether any alias-related optimizations are still needed for recent kernels though. Perhaps the SYN cache solves the original scalability problem. The hash is a reasonable modification; it'd probably be better handled through the routing code, since it has to be hashed there anyway, if you planned on using a lot of IP aliases. This patch is not needed any longer. A hash table lookup to handle large # of IP aliases was added circa 4.4R. I haven't looked at the client code, but you are aware that adding IP aliases doesn't really do anything, unless you managed your port space your self, manually, with a couple of clever tricks? In other words, you are going to be limited to your total number of outbound connections as your ports space (e.g. ~40K), because the port autoallocation takes place in the same space as the INADDR_ANY space? I guess this doesn't matter, if your maxopenfiles is only 16K, since that's going to end up bounding you well before you run out of ports... The goal here is to stress the neighbor/route code on the cache machine, this is done by generating packets from many different source IP addresses. I don't think that anything you do in this regard is going to be able to give you iMimic or NetApp level numbers, which are created by professional benchmark-wranglers, so any comparison values you get will liekly be poor, compared to commercial offerings. You're not going to get commercial quality numbers with squid. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
On Sat, Jul 06, 2002 at 11:59:50PM -0700, David Xu wrote: Jonthan, I just use DOS program as an example, for any program, if it wants to go into VM86 mode, it is very easy, just calls i386_vm86() to initailize its VM86 pcb extension, setups some memory area, then call sigreturn() to turn into VM86 mode. I think global in_vm86call flags is a bug under SMP, it creates a race condition. suppose this scenario: CPU A is running a simple VM86 code program. CPU B is running vm86_intcall() by some kernel driver (vesa module ?) CPU B set in_vm86call = 1 CPU A gets a fault trap. CPU A runs trap(), and find that in_vm86call is set and handles the trap as it is running vm86_intcall(), but it is not true and make a mess. Yes, as I mentioned earlier, the way the original vm86 bioscall worked was to prevent an AST until the BIOS was done. This relied on the giant lock for correctness, since we only allowed one CPU into the kernel at once. There probably needs to be some work done for -current in this area. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
On Sat, Jul 06, 2002 at 05:15:26AM -0700, David Xu wrote: I don't know how DOS emulating program works, but if it let DOS program run in VM86 mode, the in_vm86call global flag can prevent one CPU to run VM86 BIOS call and another CPU run DOS VM86 code, because it can not distinct which CPU the kernel is calling BIOS and which CPU is running VM86 DOS code, under SMP this is a problem. for exapmle, vesa module running on first CPU is calling VM86 BIOS, and second CPU is running DOS program, the DOS program maybe simply executes a privilege instruction to trigger trap, and the CPU will see itself calling VM86 BIOS, but it shouldn't. The virtual vm86 mode that doscmd(1) uses is different than the vm86 bios calls (or bios16, or bios32) which allows direct execution of BIOS code. They do not have much in common. doscmd() does not directly execute any of the BIOS code; it provides its own BIOS emulator. The scenario you postulate above cannot exist. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: sorry for a bit OT, does anyone see this in_vm86call crazy global variable? it prevents two CPUs to trap into VM86 model :( Um, unfortunately, this is by design. Most (all?) BIOSen code are single threaded, and the vm86 code shares the entire ISA hole, including the read/write BIOS data area. Allowing more than one CPU to execute BIOS code at once is asking for trouble, since there is no way to know what memory locations are being shared. Now that vm86_lock serves the same function, we could check that lock instead of of the global flag. I have also fixed the problem that VM86 call is preempted by interrupt threads and causes system crash. newest patch can always be gotten from : http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz I haven't looked at vm86 for a long time, but the original code worked by preventing any ASTs from being taken until the BIOS returned. It's likely that this needs to be reworked for -current. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout when it returned, this
is all difference I see, we bring in this race which not exists in RELENG_4,
see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,
I don't believe this is true. There is a corresponding race in -stable,
where the spl() level is dropped before performing the callout, thus
allowing either a call to callout_stop() or callout_reset() to come in
immediately before the callout is actually made.
The callout function is responsible for checking to see if it has lost
the race, and perform the appropriate action. This is done with the
CALLOUT_PENDING and CALLOUT_ACTIVE flags:
s = splnet();
if (callout_pending(tp-tt_delack) || !callout_active(tp-tt_delack)) {
splx(s);
return;
}
callout_deactivate(tp-tt_delack);
If 'CALLOUT_PENDING' is set, then we lost a race with callout_reset(),
and should not perform the callout. If 'CALLOUT_ACTIVE' is clear, then
we lost a race with callout_stop().
Either way, on both -current and -stable, you cannot assume that the
timer callback is completely gone immediately after calling callout_stop().
--
Jonathan
- Original Message -
From: Bruce Evans [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: Julian Elischer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 7:02 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
- Original Message -
From: Julian Elischer [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
if another thread other than softclock itself is calling callout_stop(),
and callout_stop() detected that softclock is currently running the
callout, it should wait until softclock finishes the work, then return.
softclock() intentionally releases callout_lock() to allow other processes
to manipulate callouts. What is the race exactly? Concurrent calls to
softclock() seem to be possible but seem to be handled correctly (internal
locking prevents problems). Well, I can see one race in softclock():
% c_func = c-c_func;
% c_arg = c-c_arg;
% c_flags = c-c_flags;
This caches some values, as is needed since the 'c' pointer may become
invalid after we release the lock ... but the things pointed to may become
invalid too.
% c-c_func = NULL;
% if (c-c_flags CALLOUT_LOCAL_ALLOC) {
% c-c_flags = CALLOUT_LOCAL_ALLOC;
% SLIST_INSERT_HEAD(callfree, c,
% c_links.sle);
% } else
% c-c_flags = ~CALLOUT_PENDING;
% mtx_unlock_spin(callout_lock);
callout_stop() may stop 'c' here. It won't do much, since we have already
set c-c_func to NULL, but its caller may want the callout actually stopped
so that it can do things like unloading the old c-c_func.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_lock(Giant);
% c_func(c_arg);
This calls through a possibly-invalid function pointer.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_unlock(Giant);
% mtx_lock_spin(callout_lock);
This seems to be an old bug. In RELENG_4, splsoftclock() gives a more
global lock, but there is nothing to prevent callout_stop() being run
at splsoftclock(). In fact, it must be able to run when called nested
from inside softclock(), since it might be called from the handler.
Waiting in callout_stop() for softclock() to finish would deadlock in
this case. It's interesting that this case is (always?) avoided in
untimeout() by not calling callout_stop() when c-c_func == NULL.
softclock() can't do anything about c-c_func going away after it is
called. Clients must somehow avoid killing it.
I think c-c_func rarely goes away, and the race that you noticed is
lost more often.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On Fri, Jul 05, 2002 at 02:38:08AM +1000, Bruce Evans wrote:
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout when it returned, this
is all difference I see, we bring in this race which not exists in RELENG_4,
see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,
I don't believe this is true. There is a corresponding race in -stable,
where the spl() level is dropped before performing the callout, thus
allowing either a call to callout_stop() or callout_reset() to come in
immediately before the callout is actually made.
I think Giant locking everything prevents problems in RELENG_4, at least
when callout_stop() is called in process context (if it is called in
interrupt context then it could easily be interrupting a callout even in
the UP case).
In the network stack at least, callout_stop() is called in interrupt
context, so this case actually happens, and has to be handled.
The race window extends from when the ipl or lock is dropped across the
whole callout until the ipl or lock is regained. (The ipl is only dropped
to splstatclock(); this prevents interruption by timeouts but not by
other interrupts. In -current there is nothing much to prevent softclock()
itself being called concurrently, but in theory softclock()'s internal
locking should prevent problems.)
The callout function is responsible for checking to see if it has lost
the race, and perform the appropriate action. This is done with the
CALLOUT_PENDING and CALLOUT_ACTIVE flags:
s = splnet();
if (callout_pending(tp-tt_delack) || !callout_active(tp-tt_delack)) {
splx(s);
return;
}
callout_deactivate(tp-tt_delack);
I think David is objecting to this complicating all callers that do the
check and breaking all that don't. The callers in kern_synch.c and
kern_condvar.c have an mi_switch() and other complications to handle
this sinc they can't just return.
I believe I had this conversation with Justin Gibbs earlier; he told
me that the callout consumers (network, cam) had to be aware of the
race and handle this if it matters. I don't particularly like complicating
the callout handlers as illustrated above, though, so if a better scheme
is possible, that would be nice.
I originally wanted something equivalent to an atomic spl downgrade
(splhigh - splnet), so the timeout code could obtain the target
ipl/lock that the callout handler wanted before dropping splhigh(), but
was told this would unnecessarily complicate things.
If 'CALLOUT_PENDING' is set, then we lost a race with callout_reset(),
and should not perform the callout. If 'CALLOUT_ACTIVE' is clear, then
we lost a race with callout_stop().
Either way, on both -current and -stable, you cannot assume that the
timer callback is completely gone immediately after calling callout_stop().
tsleep() seems to assume this in RELENG_4.
tsleep() is only called from process context, and appears to be safe
because p-wchan has already been cleared by a previous call to unsleep().
The races only matter if you actually care about them.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: KSE status report
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
The big problem at the moment is that something in the
source tree as a whole, and probably something that came in with KSE
is stopping us from successfully compiling a working libc_r.
(a bit ironic really).
Is the new
(elm)-field.tqe_next = (void *)-1;
in TAILQ_REMOVE a likely candidate? That could easily tickle old
bugs in other code. The libc_r code does use a lot of TAILQ macros.
From casual inspection of the sources, it appears this may be the case:
uthread/pthread_private.h:
#define PTHREAD_WORKQ_REMOVE(thrd) do { \
TAILQ_REMOVE(_workq,thrd,qe); \
(thrd)-flags = ~PTHREAD_FLAGS_IN_WORKQ; \
} while (0)
uthread/uthread_kern.c (in multiple locations):
TAILQ_FOREACH(pthread, _workq, qe) {
PTHREAD_WORKQ_REMOVE(pthread);
}
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
additional queue macro
What do people think about adding the following macro to sys/queue.h?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head, field) \
for ((var) = TAILQ_FIRST((head));\
(var) (((tmp) = TAILQ_NEXT((var), field)) || 1); \
(var) = (tmp))
Essentially, this provides a traversal of the tailq that is safe
from element removal, while being simple to drop in to those sections
of the code that need updating, as evidenced in the patch below.
--
Jonathan
Index: uthread_kern.c
===
RCS file: /ncvs/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.40
diff -u -r1.40 uthread_kern.c
--- uthread_kern.c 2002/02/09 19:58:41 1.40
+++ uthread_kern.c 2002/07/02 14:52:00
@@ -664,7 +664,7 @@
int kern_pipe_added = 0;
int nfds = 0;
int timeout_ms = 0;
- struct pthread *pthread;
+ struct pthread *pthread, *pthread_next;
struct timespec ts;
struct timeval tv;
@@ -746,7 +746,7 @@
}
PTHREAD_WAITQ_SETACTIVE();
- TAILQ_FOREACH(pthread, _workq, qe) {
+ TAILQ_FOREACH_TMP(pthread, pthread_next, _workq, qe) {
switch (pthread-state) {
case PS_SPINBLOCK:
/*
@@ -858,7 +858,7 @@
* _poll syscall:
*/
PTHREAD_WAITQ_SETACTIVE();
- TAILQ_FOREACH(pthread, _workq, qe) {
+ TAILQ_FOREACH_TMP(pthread, pthread_next, _workq, qe) {
switch (pthread-state) {
case PS_SPINBLOCK:
/*
@@ -947,7 +947,7 @@
* that is now available.
*/
PTHREAD_WAITQ_SETACTIVE();
- TAILQ_FOREACH(pthread, _workq, qe) {
+ TAILQ_FOREACH_TMP(pthread, pthread_next, _workq, qe) {
if (pthread-state == PS_SPINBLOCK) {
/*
* If the lock is available, let the thread run.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Tue, Jul 02, 2002 at 12:58:24PM -0700, Julian Elischer wrote: On Tue, 2 Jul 2002, Jonathan Lemon wrote: What do people think about adding the following macro to sys/queue.h? (I don't care much about the name, just the functionality) #define TAILQ_FOREACH_TMP(var, tmp, head, field) \ for ((var) = TAILQ_FIRST((head));\ (var) (((tmp) = TAILQ_NEXT((var), field)) || 1); \ (var) = (tmp)) Certainly this is moving in the right direction.. (acknowleging the problem).. It does the job. but if someone knows to use it then they probably also know to use a temp variable themselves. It does work in that there is very little the writer can do to screw this up. The question is simply is it waranted? It does add complexity.. I guess it needs to be added to all the other types as well (LIST, STAILQ etc) Well, as Garrett pointed out, the question also is, is this correct? It appears that the old behavior of not modifying the list pointer may actually be part of the API (although undocumented), and one way to fix the problem is to just document the behavior. Since user programs (like libc_r) may already depend on this, perhaps the most prudent choice may be to leave the original behavior alone. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FYI: Panic at in_pcbremlists()
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
I got a panic with today's current. I don't know I can reproduce this
panic or not...
This probably is in:
1015if (LIST_FIRST(phd-phd_pcblist) == NULL) {
1016LIST_REMOVE(phd, phd_hash);
1017free(phd, M_PCB);
but without the structure pointers, there isn't much to debug.
Is there a crash dump available?
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: As another example, the ipfw code uses a couple of static variables too, in the 'fwd' code amongst other places.. What is needed is obviously a 'per packet' storage location for those things, defined in a per protocol family manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. Um, no please. MT_DUMMYNET is a bad hack that should be removed (and which I've partly done in one of my trees). I would rather not perpetuate this, it causes more problems than it is worth. I believe that Garrett went in a while back and removed all the abuses of mbuf (used to store sockaddrs and the like), and this would appear to be a step backward. I don't disagree that there are many static variables that need to be cleaned up, but I don't believe that this is the right approach. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at shutdown
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: For about a week, I've been getting panics at shutdown, caused by cn_devopen() calling devsw() with a NULL dev argument. I imagine it may be related to recent changes in the console code. If it's of any interest, I have -Dh in my /boot.config. 1. A week? Why, in that time, didn't you let me know of the problem? 2. cvsup to r1.96 of tty_cons.c, which should fix this, but due to lack of testers and the inability to reproduce it here, is unverified. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: vrele: missed vn_close
Hmm. The way the revamped console code works is this: cn_devopen() calls vn_open() to open the device. If this is not a VCHR device, then it is closed. Otherwise, the vnode is stashed in cnd-cnd_vp. When the device is closed though cnclose(), it walks through a list of console devices, and if cnd_vp != NULL, calls vn_close() for that vnode, and then NULLs out cnd_vp. (drops the reference.) My understanding is that vn_open/vn_close will track the count of outstanding references to the vnode, so this should be safe to do. -- Jonathan On Wed, Oct 24, 2001 at 11:38:12AM -0700, Matthew Dillon wrote: :... :Sttopped at Debugger+0x44: pushl%ebx :db trace :Debugger() :panic() :vrele() :vn_close() :cnclose() :spec_close() :spec_vnoperate() :vclean() :vgonel() :vgone() :vop_revoke() :devfs_revoke() :exit1() :... In looking at a diff in the last few days, a huge number of changes have been made kern/tty_cons.c by jlemon. Since the area of the panic is around the same block of code there's a good chance that these changes are the cause, though I have not tested this. If so, Jonathan can locate the bug much more quickly then I can. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: vrele: missed vn_close
On Wed, Oct 24, 2001 at 11:59:52AM -0700, Matthew Dillon wrote:
:
:Hmm. The way the revamped console code works is this:
:
: cn_devopen() calls vn_open() to open the device. If this is not a
:VCHR device, then it is closed. Otherwise, the vnode is stashed in
:cnd-cnd_vp.
:
: When the device is closed though cnclose(), it walks through a list
:of console devices, and if cnd_vp != NULL, calls vn_close() for that
:vnode, and then NULLs out cnd_vp. (drops the reference.)
:
: My understanding is that vn_open/vn_close will track the count of
:outstanding references to the vnode, so this should be safe to do.
:--
:Jonathan
The panic is due to v_writecount not being properly adjusted. If a
vnode is opened with FWRITE in vn_open(), then it must be closed with
VWRITE in vn_close() or v_writecount will not be properly adjusted and cause
the panic in question to occur later in vrele().
I suspect that this is the problem with the devfs/console code.
Ugh. Probably. The console code tries to remember what flag was
used from the open, but doesn't use that flag during close.
Here's an (untested) patch - essentially it forces the FWRITE flag
always on, to avoid this problem. Possibly the right thing to do
is to used a fixed set of flags to open the console, and completely
ignore the user's specified mode.
--
Jonathan
Index: tty_cons.c
===
RCS file: /ncvs/src/sys/kern/tty_cons.c,v
retrieving revision 1.93
diff -u -r1.93 tty_cons.c
--- tty_cons.c 2001/10/23 20:25:50 1.93
+++ tty_cons.c 2001/10/24 19:36:25
@@ -365,7 +365,7 @@
{
struct cn_device *cnd;
- openflag = flag;
+ openflag = flag | FWRITE; /* XXX */
cn_is_open = 1; /* console is logically open */
if (cn_mute)
return (0);
@@ -382,7 +382,7 @@
STAILQ_FOREACH(cnd, cn_devlist, cnd_next) {
if (cnd-cnd_vp == NULL)
continue;
- vn_close(cnd-cnd_vp, mode, td-td_proc-p_ucred, td);
+ vn_close(cnd-cnd_vp, openflag, td-td_proc-p_ucred, td);
cnd-cnd_vp = NULL;
}
cn_is_open = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?
On Fri, Oct 19, 2001 at 04:58:21PM -0700, Mark Peek wrote:
At 11:23 AM +0200 10/18/01, Harti Brandt wrote:
On Thu, 18 Oct 2001, Max Khon wrote:
MKhi, there!
MK
MKOn Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:
MK
MK On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
MK I've seen this when DHCP fails to allocate an address.
MK
MK
MK But I am not using DHCP. Maybe there are other machines in the LAN (it is
MK a *big* LAN) trying to get their addresses using DHCP, and now -CURRENT
MK shows a message whenever detects one of those packets. I will try to
MK identify the senders (over 40!).
MK
MK Anyway, these 0.0.0.0 ARP messages are new in -CURRENT, and none of our
MK machines running FreeBSD 4.x show them.
MK
MKhow current -CURRENT are you running?
I have these two on a yesterday's current and remember that they appeared
after I saw a commit message approx. 2 weeks ago about adding hashing of
inet addresses (maybe rev. 1.83 of if_ether.c).
Yes, it does appear to be due to this commit. The first address on the
interface queue has an address of 0.0.0.0. Here's a patch that works for
me to block the messages. I'm guessing at the correct behavior so use at
your own risk. At least the voices^Wlog messages have stopped. :-)
Below is the patch that I've sent to the people who reported the
problem, I'm waiting to hear back from them that it works.
--
Jonathan
Index: if_ether.c
===
RCS file: /ncvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c 2001/10/17 18:07:05 1.85
+++ if_ether.c 2001/10/19 15:38:07
@@ -593,10 +593,12 @@
isaddr.s_addr == ia-ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
+* No match, use the first inet address on the receive interface
* as a dummy address for the rest of the function.
*/
- ifa = TAILQ_FIRST(ifp-if_addrhead);
+ TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
+ if (ifa-ifa_addr ifa-ifa_addr-sa_family == AF_INET)
+ break;
if (ifa == NULL) {
m_freem(m);
return;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: my dc now doesn't work
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: After the last cvsup (changes from 29 of september) i've got dead dc (21143 based NIC). LEDs are dead, but card is successfully probed and attached, so i have device but can't use it. What should i send to help investigate this problem? $FreeBSD: src/sys/pci/if_dc.c,v 1.56 2001/09/29 19:28:31 jlemon Exp $ Can you back out this last change to if_dc, and see if that fixes the problem that you're having? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KRIS: FOR YOU TO COMMIT: soft interrupt coelescing
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Clearly this would also be very applicable to non-Gigabit cards, but the only one we use is the FXP, and the FXP driver is very poorly structured for being able to do this type of thing (I Oh, bah. The fxp clearly has the equivalent of fxp_rxeof and fxp_txeof routines, these are just inlined into the fxp_intr routine instead of being separate functions. It was all of 10 minutes work to break them out into separate functions. I did this to allow polled transmit/receive for some work in progress that will be committed soon. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: In message [EMAIL PROTECTED] Jim Bryant writes: : I doubt if the bootloader will ever change from FORTH, but if it : does, I suggest LISP as the preferred choice on a short-list of : potential replacements. It would make it very cool junior kernel hacker task to use lisp in the boot loader... Hmm. Other cool tasks include: - substituting TAB for space in correct places and vice versa. - fixing incorrect code indentation. - wholesale removal of _P() prototypes. - rewriting all perl scripts in sh. - using Java instead of C in the kernel. All of the above will provide much needed features and functionality for the upcoming 5.0 release. They will dramatically raise the bar and provide a significant performance boost for the system. After all, it is well known(*) than LISP is already SMP capable, while Forth is single threaded, and it is critically important that the bootloader be SMP enabled. :-) Seriously now, don't we have better things to spend our time and energies on than re-implementing code that already works? -- Jonathan (*) 4 out of 5 handwavers agree on this point, according to the Journal of Irreproducible Results and Department of FUD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: net-snmp port on -CURRENT?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Hi... I am trying to build net-snmp port on -CURRENT but don't have enough luck with it. Here's the error message on my system: -- cc -DINET6 -O -pipe -march=pentiumpro -Dfreebsd5 -I. -I../.. -I. -I./../.. -I./../../snmplib -I./.. -I.. -c host/hr_storage.c -fPIC -DPIC -o host/.libs/hr_storage.lo host/hr_storage.c: In function `var_hrstore': host/hr_storage.c:526: structure has no member named `m_mbufs' host/hr_storage.c:565: structure has no member named `m_clusters' host/hr_storage.c:565: structure has no member named `m_clfree' *** Error code 1 The mbuf subsystem has been rewritten for -current, and mbuf statistics are handled differently now. The port will have to be updated to teach it about the new statistic layout. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fxp SCB timeout problems [FIX]
On Tue, Aug 28, 2001 at 09:32:22AM -0600, Brad Huntting wrote: From my perspective, negative functionality is being lost. There is a nice comment in the source code explaining what it is... * Enable workarounds for certain chip revision deficiencies. * * Systems based on the ICH2/ICH2-M chip from Intel have a defect * where the chip can cause a PCI protocol violation if it receives * a CU_RESUME command when it is entering the IDLE state. The * workaround is to disable Dynamic Standby Mode, so the chip never * deasserts CLKRUN#, and always remains in an active state. * * See Intel 82801BA/82801BAM Specification Update, Errata #30. Will the card be able to function in suspend mode and do Wake-on-LAN correctly after this? It should still do wake-on-lan, although the fxp driver doesn't support that right now - it doesn't appear to be a useful feature. Powersave transitions (D0 - D3) should also still work. What the fix does is prevent the board from reducing power in idle state, which is a subset of D0. (Intel has D0-active and D0-idle, or some such). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fxp SCB timeout problems [FIX]
I believe that I have a real fix for the SCB timeout problems that have been plauging users of recent Intel fxp boards. If you have a board that uses the Intel ICH2/ICH2-M chipset (usually 815E style boards) and feel comfortable applying patches to the system, please contact me to test a fix. The patch works on two different boards here, but I would like to get some wider testing before I commit it to the tree. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm86 problem in -CURRENT
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: As far as I understand, the entire 1M bytes of lower physical memory is supposed to be mapped when vm86_intcall() is run. Apparently 0xc, where the video BIOS ROM resides, is mapped OK. But, somehow 0xa, where the video ram is, went missing. As I wrote before, this test program sometimes runs fine, sometimes does not. When you make a vm86 call from the kernel, it uses a private page table (located at vm86paddr) in order to map the pages. The details of the layout can be found in i386/i386/vm86.c. This page table is initially populated in locore.s, and contains only page 0 + the ISA hole (0xa - 0x10). If getmemsize() detects that there is a hole between basemem and ISA memory, the pages in this hole will additionally be mapped into the vm86 space. If you're getting a page fault while trying to access 0xa, then it would seem that the entries in the vm86 page table are incorrect. You can check this by examining the page table located at vm86paddr. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New Mbuf Allocator (some graphs)
On Fri, Jun 15, 2001 at 06:54:21PM -0400, Bosko Milekic wrote: Hi Folks, Here are some performance results. Keep in mind that we're still under Giant. http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html Just for comparision, 6-way results are at: http://www.flugsvamp.com/~jlemon/fbsd/netpipe/ -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New Mbuf Allocator (some graphs)
On Fri, Jun 15, 2001 at 07:44:59PM -0400, Bosko Milekic wrote: On Fri, Jun 15, 2001 at 06:32:55PM -0500, Jonathan Lemon wrote: On Fri, Jun 15, 2001 at 06:54:21PM -0400, Bosko Milekic wrote: Hi Folks, Here are some performance results. Keep in mind that we're still under Giant. http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html Just for comparision, 6-way results are at: http://www.flugsvamp.com/~jlemon/fbsd/netpipe/ Are you sure those aren't inverted? (i.e. swap(present, mb_alloc)?) Yup, I'm sure. The 'local' tests were done last night, the 'stream' tests were done today with the same pair of kernels. In any case, the mb_alloc code you used still has the malloc() and free() calls during cluster allocation and freeing and still, it looks to me as very comparable nonetheless. The results look good to me; the only thing that really stands out is the signature graph for stream tests; that odd curve at the start of the run. However, if I'm interpreting it correctly, it shows better performance in the mb_alloc case. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New Mbuf Allocator (some graphs)
On Fri, Jun 15, 2001 at 07:44:59PM -0400, Bosko Milekic wrote: Here are some performance results. Keep in mind that we're still under Giant. http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html Just for comparision, 6-way results are at: http://www.flugsvamp.com/~jlemon/fbsd/netpipe/ Are you sure those aren't inverted? (i.e. swap(present, mb_alloc)?) In any case, the mb_alloc code you used still has the malloc() and free() calls during cluster allocation and freeing and still, it looks to me as very comparable nonetheless. I've updated the page with results from running Bosko's latest code (without the malloc/free calls). The results are at the above URL. The performance of the new allocator on this benchmark comes out ahead of the old one. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tail -f over NFS in -stable
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
Blast from the past. This patch seemed reasonable to me at the time, but I
notice you didn't commit it. Any reason why? The issue has just come up
again on -questions.
It shouldn't be needed. Instead, the following logic is used:
if (kevent(kq, ev, n, NULL, 0, ts) 0) {
close(kq);
kq = -1;
action = USE_SLEEP;
Registration of a VNODE filter on a filesystem that doesn't understand
it (NFS) should fail. Hardcoding ufs in the binary is the wrong thing
to do; it precludes kernel enhancements later where other filesystems
are taught about kqueue.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
On Sat, May 05, 2001 at 04:04:27PM -0700, Archie Cobbs wrote: Jonathan Lemon writes: Please consider the case where there are two mbuf chains being transmitted, which look like this: Um. Not Possible. I thought m_copypacket() of a cluster mbuf would yield exactly this situation (two headers pointing to the same data region). Well, only external mbufs can be shared, not mbuf chains; and clusters are accessed through the (unused) mbuf that comprises the chain. I believe Terry may have been referring to some local modifications that is in his code, which permits the scenario he describes. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
] I would be quite interested in knowing just how you manage
] to accomplish that, given that all the transmit control buffers
] are arranged in a circular linked list:
]
] fxp_init(void *xsc)
] {
] ...
] for (i = 0; i FXP_NTXCB; i++) {
] ...
] txp[i].next = txp[(i + 1) FXP_TXCB_MASK];
] }
]
]
] I would suggest actually examining the rest of the code to see
] how it works before making erroneous proclamations based on the
] myopic examination of a single statement.
I would suggest a less than myopic examination of the subject
line.
I'm quite aware of the subject line; but you're changing the
subject here. Any panic has nothing to do with the next pointer
being NULL, as you stated in the previous email, since this is
not possible, assuming correct operation of the code.
In particular, I saw a repeatable panic under extremely heavy
load.
I'm sorry, my MTA must have dropped your bug report, as it appears
to be missing. Can you please resend? In particular, a stack
backtrace and preferably a crashdump, and leave off any wild
hypothesis of where the bugs are, unless you have supporting evidence.
Please consider the case where there are two mbuf chains being
transmitted, which look like this:
Um. Not Possible.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
txp = txp-next) {
if (txp-mb_head != NULL) {
m_freem(txp-mb_head);
txp-mb_head = NULL;
}
sc-tx_queued--;
}
...notice the for loop doesn't check to see if txp = txp-next
ends up being NULL? You can get this, if you put your system
under extreme load.
I would be quite interested in knowing just how you manage
to accomplish that, given that all the transmit control buffers
are arranged in a circular linked list:
fxp_init(void *xsc)
{
...
for (i = 0; i FXP_NTXCB; i++) {
...
txp[i].next = txp[(i + 1) FXP_TXCB_MASK];
}
I would suggest actually examining the rest of the code to see
how it works before making erroneous proclamations based on the
myopic examination of a single statement.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SOMAXCONN -- not tunable?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Here are patches to make SOMAXCONN tunable from the config files. Right now, it's not possible to override SOMAXCONN. sysctl -w kern.ipc.somxconn=1024 SOMAXCONN is just a compile time default, and yes it is not currently tunable at config time. Does it really have to be? Just stick it in /etc/sysctl.conf, and it gets set before most things are started in the system. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/gen glob.c
On Fri, Mar 16, 2001 at 03:58:13PM -0500, Will Andrews wrote: On Fri, Mar 16, 2001 at 11:05:20AM -0800, Jonathan Lemon wrote: Log: Bump MAX_GLOBENTRIES up to 16384, so it is a power of two. Add some comments explaining that this is an arbitrary limit. Why shouldn't this be tunable via sysctl? Uh, because this is user space, not kernel space? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP **
On Thu, Mar 15, 2001 at 11:13:09AM -0600, Peter Schultz wrote: On Mon, Mar 12, 2001 at 05:52:00PM -0600, Jonathan Lemon wrote: I committed a miibus'ified fxp driver to the tree today, and made it the default. If you compile fxp into your kernel statically, you will also need "device miibus" as well, if it isn't there already. If you notice any problems with the driver (things that were working and are not working now), please let me know. If you happend to have a chip that did _NOT_ work but now DOES work, please boot the machine with -v, and send me the line that says "PCI IDs:". If you have a fxp device that still doesn't work, then please get in touch with me (and send the output of the line above). -- Jonathan Hi Jonathan, I've got a slight problem in that it is not correctly auto detecting the media type. It should be setting itself to 10baseT/UTP. I'm running DHCP on my -current machine and I'm not sure how to set it so that it configures the interface correctly. It previously "just worked" without any special media settings. Is there something I can provide to help correct this? Well, first off, you should be able to force the media settings of the chip with 'ifconfig fxp0 media 10baseT/UTP', even before DHCP configures the interface address. Second, I'll need more details about your system. At the minimum, can you get a verbose boot and send me the relevant information about the adapter (fxp, inphy, nsphy, PCI IDs line). Thanks! -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP **
I committed a miibus'ified fxp driver to the tree today, and made it the default. If you compile fxp into your kernel statically, you will also need "device miibus" as well, if it isn't there already. If you notice any problems with the driver (things that were working and are not working now), please let me know. If you happend to have a chip that did _NOT_ work but now DOES work, please boot the machine with -v, and send me the line that says "PCI IDs:". If you have a fxp device that still doesn't work, then please get in touch with me (and send the output of the line above). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DNS kqread (kq in general)
I"ve committed a fix for the problem where DNS hangs or takes a long time to resolve (the process gets stuck in kqread). In the last kqueue update, I added a new filter-specific flag to the read/write filters, which allows the filter to specify its own read/write watermarks. However, since this flag was previously unused, if you do not initialize the structure to zero, you may get unexpected results. To that end, I'd encourage kqueue users to review their code and make sure that the structure is completely initialized. A new a new convenience macro EV_SET() was also added to sys/event.h which should also assist this process. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: resolver problem with shared linked programs
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: At first I thought something is wrong with my ipv6 dns setup, but it turned out that if a program is linked shared the first getipnodebyaddr() it does will succeed, but the rest fail. For a staticly linked program all of them will succeed: I just fixed this a few minutes ago. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] for linux_connect (ugly)
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Some background: when a socket is connected in non-blocking mode and the connect does not immediately succeed (i.e. EINPROGRESS is returned), linux obviously will return the value getsockopt(...SO_ERROR...) on the socket would give on FreeBSD (i.e. 0 if the connection attempt succeeded) from the first connect() call on the socket after the connection has been established. Only the next call will returne EISCONN. So, the linuxulator has been modified in the past to always return the value getsockopt(...SO_ERROR...) gives. This does break applications that loop and wait for EISCONN, e.g. StarOffice. Let me get this straight, just so I understand the behavior: 1. socket is marked non-blocking. 2. connect() is made, does not immediately succeed, returns EINPROGRESS 3. connect() call is repeatedly made, EALREADY is returned. 4. connection finally established, connect() returns EISCONN Is this the correct/desired behavior? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tail -f kernel panic
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I found it is quite easy to panic a -current kernel with 2 login windows. In window 1 do a "tail -f /tmp/world.out" In window 2 do a "tail -f /tmp/world.out" In window 2 do "^C" to break out of tail -f In window 1 do "^C" to break out of tail -f The box panic immediately. Hmm. I reproduced this here; the panic is in SLIST_REMOVE() when it is removing the second event. Funny enough, this does not happen on -stable. Did something change in the list macros recently that would cause this? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tail -f kernel panic
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: I found it is quite easy to panic a -current kernel with 2 login windows. In window 1 do a "tail -f /tmp/world.out" In window 2 do a "tail -f /tmp/world.out" In window 2 do "^C" to break out of tail -f In window 1 do "^C" to break out of tail -f The box panic immediately. I just commited a fix for this. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote:
Oh, I suppose, I did find that... well, mainly I wanted the person who made
the change to actually broadcast to NIC maintainers what the expectations
were...
The code that prints these warnings out has existed for a while. However,
whoever added it made a bad assumption about the internals of the mutex
implementation, so the code never got executed. I "fixed" it last week, so
the warnings get printed now.
Actually, I think it was correct at the time I added it. Anything
that calls if_attach (or ether_ifattach) will automatically have the
mutex correctly initialized, so the driver doesn't have to do anything
extra.
e.g.:
ifp-if_name = "lo";
ifp-if_unit = i++;
ifp-if_snd.ifq_maxlen = ifqmaxlen;
if_attach(ifp);
if_attach(ifp)
{
mtx_init(ifp-if_snd.ifq_mtx, ifp-if_name, MTX_DEF);
...
}
I'm not up-to-date with -current at the moment, so I'm not sure
why things aren't working any more.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: XXX driver didn't initialize queue mtx
On Sat, Jan 27, 2001 at 01:05:58PM -0800, Jason Evans wrote:
On Sat, Jan 27, 2001 at 12:48:36PM -0800, Matthew Jacob wrote:
Somewhere in between, Jason Evans wrote:
On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote:
Oh, I suppose, I did find that... well, mainly I wanted the person who made
the change to actually broadcast to NIC maintainers what the expectations
were...
The code that prints these warnings out has existed for a while. However,
whoever added it made a bad assumption about the internals of the mutex
implementation, so the code never got executed. I "fixed" it last week, so
the warnings get printed now.
Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to
initialize these prior to calling ether_ifattach?
Look- I just want to know what the people who put the check in *want*.
cvs annotate is your friend. The code was added in revision 1.95 of
src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should
be done to fix the drivers.
Actually, the new check appears to be incorrect, as seen by the code
fragments below:
#define MTX_DEF 0x0 /* Default (spin/sleep) */
mtx_init(ifp-if_snd.ifq_mtx, ifp-if_name, MTX_DEF);
mtx_init(... , flag)
{
...
m-mtx_flags = flag;
...
}
if (ifp-if_snd.ifq_mtx.mtx_flags == 0) {
So the warning will always be printed out even though the mutex is
correctly initialized.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
On Sun, Nov 26, 2000 at 01:06:12PM -0600, Michael Harnois wrote: On 26 Nov 2000 12:48:48 -0600, Michael Harnois [EMAIL PROTECTED] said: OK, I think I have it now. Remove sys/mbuf.h and change machine/mutex.h to sys/mutex.h. Except that the kernel won't build if sys/mbuf.h isn't included. Oh well. Yes; I"m testing a fix with: #ifdef _KERNEL #include sys/mbuf.h #endif /* _KERNEL */ #include sys/mutex.h My machines are churning through a make world right now.. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
On Sun, Nov 26, 2000 at 11:23:45AM -0800, Alfred Perlstein wrote: * Jonathan Lemon [EMAIL PROTECTED] [001126 11:18] wrote: On Sun, Nov 26, 2000 at 01:06:12PM -0600, Michael Harnois wrote: On 26 Nov 2000 12:48:48 -0600, Michael Harnois [EMAIL PROTECTED] said: OK, I think I have it now. Remove sys/mbuf.h and change machine/mutex.h to sys/mutex.h. Except that the kernel won't build if sys/mbuf.h isn't included. Oh well. Yes; I"m testing a fix with: #ifdef _KERNEL #include sys/mbuf.h #endif /* _KERNEL */ #include sys/mutex.h My machines are churning through a make world right now.. Ick, shouldn't it just be required that one include sys/mbuf.h before this include file? Probably, but I want to unbreak -current quickly. :-( -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld broken ... CVS from today ...
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Just tried to do a buildworld, got as far as netstat before it barf'd with: === usr.bin/netstat cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC -I/usr/obj/usr/local/base/src/i386/usr/include -c /usr/local/base/src/usr.bin/netstat/if.c In file included from /usr/obj/usr/local/base/src/i386/usr/include/net/if_var.h:78, from /usr/local/base/src/usr.bin/netstat/if.c:49: /usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' undeclared here (not in a function) Already fixed. -- Joanthan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: On Fri, 17 Nov 2000 10:30:02 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: what the WITNESS code does is perform extra checks on mutex enter's and exit's to ensure that we aren't handling mutexes in such a way that a deadlock is possible. Thus, it verifies that you don't grab mutexes out of order, or that you don't grab sleep mutexes with interrupts disabled, etc. Is this code meaningful on UP machines? Having been a victim of these seemingly random freezes since SMPng started, as others have noted, I decided to compile it in earlier this week. Twice now I've been dumped into the debugger with this output: lock order reversal 1st dc0 last acquired @ ../../pci/if_dc.c:2717 2nd 0xc0acdb3c dc1 @ ../../pci/if_dc.c: 2717 3rd 0xc0acab3c dc0 @ ../../pci/if_dc.c: 2929 This is on a UP machine? This looks like you're taking an interrupt on dc1 and then trying to call the dc0 start routine, which shouldn't be possible. (Unless I'm misunderstanding the witness code) What version of if_dc.c are you using? line 2929 doesn't correspond to an instance of "DC_LOCK" in my copy. -- Jonathan this should be released before anything else To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: today's -current xl0 wigs out
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Well getting rid of the leftover splimp() didn't clear up the problem. Maybe we need to move the mtx_init and XL_LOCK up to where the splimp() was. Change the last XL_LOCK in xl_intr() into an XL_UNLOCK. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tail after kqueue changes
On Thu, Jun 22, 2000 at 05:25:55PM +0200, Alexander Leidinger wrote: Hi, I'm using the "-F" option of tail for some files which get rotated away. After the changes to use kqueue/kevent it didn't work as expected anymore. tail exits after the file gets rotated. Perhaps it didn't wait long enough to see the new file: I did a "tail test.txt" in one terminal and a "mv test.txt; touch test.txt" in another and I got "tail: test.txt: No such file or directory". I got a little too aggressive when following the file; it wouuld switch to the new file immediately, and get upset when it couldn't find it. I've just committed a fix which allows for a window of time where the file doesn't exist at all, which should solve the above problem. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Am I the only person who miss a brief document which tells what the outcome of the meeting was ? I believe that Jason Evans already sent a message summarizing the meeting, and Matt Dillon's webpage gives a pretty good summary of the work too (at http://apollo.backplane.com/FreeBSDSmp/) Can we get to see the slides ? Chuck Patterson presented a bunch of slides (which was actually a .ps file that displayed page by page in gv), so perhaps he could be persuaded to make the entire postscript file available somewhere. Audio ? Video ? After several mishaps, I believe that Greg finally got a video camera up and running for most of the session. I think that it was in PAL format as well. Greg has the tapes, so I assume that after he's done with USENIX, he'll have them available. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP + APM = panic - fixed!
On Wed, Jun 07, 2000 at 02:06:15AM +0900, Mitsuru IWASAKI wrote: We're having this problem for long time (from the old 4.0-CURRENT days), but Mr. SUMITANI discovered a bug and fixed it. The problem was that we got worng gdt pointer for the current cpu, then panic... The followings is a patch to fix the problem. Thanks a lot, SUMITANI-san! Please test this and I'll commit MFC this if we have no problem with this fix. I don't have an SMP + APM system around at the moment, but the fix does look correct to me, go ahead and commit it. Thanks for tracking this down! -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT broken. (in_cksum changes)
On Wed, May 10, 2000 at 01:49:51AM +0900, MIHIRA Yoshiro wrote: On Sun, 7 May 2000, Nick Hibma wrote: Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I had same problem with below options: optionsIPFILTER#ipfilter support optionsIPFILTER_LOG#ipfilter logging optionsIPSEC #IP security I think this problem related to jlemon-san's commit. Yes, my abject apologies. I just committed Nick's fix to the tree to resolve this. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: event.h troubles
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Now I got lost of /usr/include/sys/event.h:159: warning: `struct timespec' declared inside parameter list. because sys/select.h include it. Please fix somehow. I'm looking at this now. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: event.h troubles
On Tue, Apr 18, 2000 at 10:17:36AM -0700, Matthew Dillon wrote: :In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: :Now I got lost of : :/usr/include/sys/event.h:159: warning: `struct timespec' declared inside :parameter list. : :because sys/select.h include it. :Please fix somehow. : :I'm looking at this now. :-- :Jonathan this just means you have: int fubar(struct blah *ptr) ... Where 'struct blah' has not been previously struct. This is one of those broken ANSIsms. The solution is simple: Yeah, I know, but I fed the change through a full buildworld anyway to make sure I didn't break anything else. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP; kq related changes
I just committed kq support to the tree. The first thing I forgot to mention in the commit log is that the size of `struct proc' changed, so a full buildworld is in order. Second, a man page is forthcoming, so if you're looking for that, wait a day or two. (I'm better at writing code than man pages, but will be happy to answer questions about this). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Transparent proxying using ``ipfw fwd'' seems broken as of today
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Is it just me or is anybody else seeing this as well with today's kernel/world? Yes, green just brought this to my attention. I've committed a fix that should solve the problem. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using packed structs to gain cheap SMP primatives
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
* Allen Pulsifer [EMAIL PROTECTED] [000329 21:05] wrote:
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
order that nothing has changed. For example, to read a
structure containing hours, minutes, seconds:
for (;;)
{h = timep-hour;
m = timep-minute;
s = timep-second;
if (m != timep-minute) continue;
if (h != timep-hour) continue;
break;
}
The assumption is that from the instant you first read
timep-hour until the instant you double check its value,
it could not have wrapped all the way back around to its
previous value. Or to put it another way, if it has
succeeding in wrapping all the way around, having a
correct snapshot of the structure is the least of your
problems and the value you use is arbitary.
This same method can be used to read the MSW and LSW of
any counter-like structure that is updated by an interrupt.
Note this method will not work for a structure that can
both increment and decrement--it has to be only one or
the other.
I'm aware of this, the problem is that tz may move in either
direction. Hence my question about using sizes that are machine
atomic for read/write. :)
I've got several books on various systems here and I don't remeber
any of them mentioning a problem with 32bit aligned updates being
atomic.
Each architecture will define what is atomic or not. Most modern
architectures will provide atomic access to their native word size,
provided it is aligned on a natural word boundary.
On the PPro and upwards, 64 bit reads/writes to quadword aligned
structures are atomic. it's just too bad that there is no direct
64-bit read insn (excluding FP).
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Somebody broke alpha kernel builds?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mno-fp-regs -Wa,-mev56 ../../alpha/alpha/clock.c ../../alpha/alpha/clock.c:83: syntax error before `alpha_get_timecount' ../../alpha/alpha/clock.c:83: warning: type defaults to `int' in declaration of `alpha_get_timecount' ../../alpha/alpha/clock.c:83: warning: data definition has no type or storage class .. Speaking of which, why is /home/ncvs on beast not pointing to the current CVS repository? I got bit by the same error after doing (what I thought) was a correct `cvs update' on beast. On Freefall: /home/ncvs@ - /x/ncvs On Beast: freefall:/x on /.amd_mnt/freefall/host/x /home/ncvs@ - /j/ncvs -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
In article local.mail.freebsd-current/2310101848$[EMAIL PROTECTED] you write: Work on this driver is stalled owing to the fact that nobody that can and wants to work on it has access to the Compaq hardware required. You can't use these controllers except in Compaq systems, which makes things very difficult. that's true :-( Again I would like to point out, that only the newest controllers, 3200 and up is difficult getting to work in non-Compaq systems: http://seeberg.dk/freebsd/idaraid Note that I just committed some more changes to the IDA driver to 4.0-RC yesterday. The changes are: - support for EISA controllers (untested) - support for newer S2400 controllers (untested) - addition of IDA to the GENERIC kernel - support for installing directly onto the RAID array. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
On Fri, Mar 10, 2000 at 11:45:19AM -0600, Alejandro Ramirez wrote: Hi Jonathan, Note that I just committed some more changes to the IDA driver to 4.0-RC yesterday. The changes are: - support for EISA controllers (untested) - support for newer S2400 controllers (untested) - addition of IDA to the GENERIC kernel - support for installing directly onto the RAID array. Are there any plans to add some utility to configure (or reconfigure) the array under FreeBSD??? Unfortunately, no. That would require documentation on the controller, and so far, Compaq hasn't shown any inclination to release information. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Kai Großjohann wrote: "Jordan K. Hubbard" [EMAIL PROTECTED] writes: I really kinda wish you'd point them to Novice^H^H^H^H^HStandard instead since it does more than be a bit more verbose, it also makes sure that all the appropriate steps are covered and prevents even relatively skilled people from hanging themselves. Does this mean that this option should be called `guided'? I know a little bit about Unix but haven't installed FreeBSD more than five times or so. And I always thought that the novice install meant that I didn't get as many choices... "Guided". I like it. That's *PRECISELY* what this installation option is. There is NO difference in the number of choices available in any of the three types. Guided/Express/Expert. That's my vote. Cool, seconded. I actually use "novice" most of the time, simply because I like the hints that help me not to screw up, and I've been using this option (or equivalent) since 1.1.5 at least. Guided sounds like a better description to me. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Odd TCP glitches in new currents
On Dec 12, 1999 at 11:37:42AM -0800, Matthew Dillon wrote: I finally tracked it down. The loss is occuring in the link between two of my switches. The link goes across my apartment - about 60 feet of Cat-5 cable. That should be well within spec (you are supposed to be able to do 100 meters) but it causes packet loss. The switches autonegotiate full-duplex for the link (and I verified that it's actually running at full duplex), but that's where the packet loss occurs. Very weird. I was finally able to fix it by dropping in a 10BaseT hub to force the switches to negotiate 10BaseT across the link. Maybe my cable is damaged or something. I'll run a second cable to see if that's the problem or whether. The second switch is a LinkSys. I have a D-Link near my servers and a LinkSys near my workstation. Another thing I to keep in mind, is that sometimes the switch is bad. I had a Netgear FS509 switch here that would eat packets transmitted through the GigE port under certain conditions. Netgear shipped me a new one, and I've been happy with it, until the same problem started happening again this morning. Perhaps in this case, it's a bad fiber cable, I'll have to do some more testing to track it down. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)
On Dec 12, 1999 at 01:41:04AM -0500, Bill Paul wrote: Of all the gin joints in all the towns in all the world, Matthew Dillon had to walk into mine and say: I'm adding Bill Paul to the list specifically. Hmm. Now this is odd! I think I may have found something! All of my 'rl' driver cards fail this test: Oh sure. Bet the farm on the absolute worst NIC on the whole damn planet, why don't you. Sorry, but I can't resist quoting this: /* * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is * probably the worst PCI ethernet controller ever made, with the possible * exception of the FEAST chip made by SMC. */ -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP sockets stuck in the CLOSING state
On Nov 11, 1999 at 01:41:48PM +0100, Dag-Erling Smorgrav wrote: [bringing this back to -current, with a Bcc to -security] "Kenneth D. Merry" [EMAIL PROTECTED] writes: Jonathan Lemon wrote... In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Before I spend a lot of time hunting this down, I figured it might be worth asking -- is there any particular reason why TCP sockets may be getting stuck in the CLOSING state more often now? Not sure. But here's a tcpdump trace of a socket that ends up in the CLOSING state. (on the host ``cache''). [...] 1. the other end (folly) never acks the FIN. The packets at timestamp .492154 and .492160 do not cover the FIN in the sequence space. Yet the host `folly' closes the socket. This is weird, and probably deserves some investigation (at least if cache and folly are on the same LAN; otherwise there's a non-zero possibility of the ACK simply getting lost on the way) Good point. I'll try taking a tcpdump on both sides to see if the ACK is getting lost, or if it just isn't getting sent at all. Note that the state transition diagram in RFC793 does not specify a timeout for the CLOSING - TIME_WAIT transition, so any faithful implementation of RFC793 has this bug (but why doesn't this happen on -STABLE, or on pre-August -CURRENT?) I'm not sure abuot that one. But I've just committed a fix to tcp_fsm.h, which will cause it to re-transmit a FIN in CLOSING state. The FIN was originally taken out by Garrett in rev 1.5, and restored by dg in rev 1.6. However, it was re-removed in 1.10 when Garrett made a large commit, presumably he hadn't taken it out of his local tree. It fixes the problem here (at least, I can't replicate the problem any more). I'm not sure if I'm fixing the symptoms rather than the actual problem then, though. NetBSD has the same fix in their tree as well. I'm pretty sure that I've seen this problem on -current going back as early as March as well. This hints at a potential DoS vulnerability. Hack a TCP stack to never acknowledge FIN segments, and blast away at your victim; chances are he'll run out of mbufs before you run out of source ports (each source port can only be used once in the attack). Give me a few hours and I might be able to verify this vulnerability experimentally. Do let me know if this is the case. I was considering this last night, but was too tired to try an figure out how to generate a TCP stream that would ACK everything but the FIN. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Compaq SMART-2SL array controller
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: After doing a cvsup yesterday evening i can't seem to boot on my raid cotroller using the same kernel config. Is -current probing hardware i a different way now or ?? It appears so. The IDA driver needs to stomp on the WD driver's vectors in order to boot off of the RAID controller. It seems that something changed so that wd is getting probed after the ida driver now, and removing the vectors. For now, you could remove the IDE devices from the config file, until this gets fixed. Ideally, the boot blocks/loader should be taught to boot from something other than wd() or da(). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Compaq SMART-2SL array controller
On Sep 09, 1999 at 01:26:35PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Jonathan Lemon writes: : It appears so. The IDA driver needs to stomp on the WD driver's : vectors in order to boot off of the RAID controller. It seems that : something changed so that wd is getting probed after the ida driver : now, and removing the vectors. Is this so that it could mount root? In 3.x the only way to do this is to have a special disk label type. I've hacked things to get fla bootable on -stable using this method. The sysinstall program hasn't been updated, however. Yes. The IDA driver will be happy with it's own device nodes (/dev/ida), but last time I checked, the boot/loader would only understand root devices of wd() or da(). I understand that Soren's ad() driver has the same problem. -- 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 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
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
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: 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 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: recent apm changes
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
In FreeBSD, when I activate suspend mode, I see the light on my
computer blinking, indicating it has gone into suspend mode, but still
there is no reduction in noise whatsoever. The disks keep spinning,
the CPU fan (or whatever) too. I could activate the BIOS spindown
timer on the HDD's, but I'd rather not (since then I also get
spindowns while I'm normally working with the computer) but still the
other fan will always continue to run.
What can I do to change this behaviour? Can anyone explain what Linux
(or Win95 for that matter) are doing to make it 100% quiet in suspend
mode? Then I could give it a try to have FreeBSD do the
same. Currently this prevents me from using FreeBSD alas.
FreeBSD's APM suspend works by sending the BIOS a suspend event
for all BIOS managed devices, and the BIOS is supposed to put
all devices under it's control into the "low-power suspend" state.
I'd guess that this isn't the same as "off". You can't tell the
BIOS to turn off all devices, you need to specify which devices
to turn off.
You could play around with adding something like this to
apm_suspend_system (for your hdd:):
sc-bios.r.eax = (APM_BIOS 8) | APM_SETPWSTATE;
sc-bios.r.ebx = 0x02ff;
sc-bios.r.ecx = state ? PMST_APMENABLED : PMST_OFF;
sc-bios.r.edx = 0;
if (apm_bioscall())
printf("Failed to turn off HDD: errcode = %d\n",
0xff (sc-bios.r.eax 8));
Of course, you'd probably also need a corresponding "turn on", call
somewhere. As for your fan, I'm not sure what the deviceid for the
fan would be, the "0x02ff" above means "all 2ndary storage devices".
Perhaps "0x80FF", for all OEM devices.
At the moment, there isn't the ability to control individual devices,
but at some point, I can see this being added to the new-bus architecture;
each device can register callbacks for various power management events.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4-way SMP broken ?
In article local.mail.freebsd-current/199906092225.saa01...@par28.ma.ikos.com you write: Also in trying to figure this out I looked at the DRAM probing code in /usr/src/sys/i386/i386/machdep.c:getmemsize(), and it looks as though it's not safe for 2GB (e.g. comparisons of byte addresses against signed int end). I just made this into a vm_offset_t, so it should be good for up to 4GB. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Request for testers; removing VM86 as an option.
I have a patch that reworks the memory calculation at bootup, and correctly obtains the physical memory map from the BIOS using the INT 15, AX=E820 call. This should allow correct operation on machines which reserve certain segments of memory for non-OS use (ThinkPads). It can also preserve the ACPI tables for later use. If 15/E820 is not supported, various other methods are tried, including falling back to the current scheme of speculative probing. I'd like some testers (preferrably a ThinkPad user with 64M of memory) to try this out and see if it correctly detects all usable memory; and also if the system boots without needing to specify MAXMEM (or npx0 size). If it works, great. If not, boot with `-v', and send me back the SMAP lines from the dmesg output. Barring any serious objections(*), I'd like to merge this into -current, and then `unifdef -DVM86' to make it mandatory. There appears to be no other reliable way to detect 64M of memory on modern PC hardware. PC98 developers - this should actually simplify things, as it moves the memory calculations into their own routine. The -current patch is ftp://sumatra.americantv.com/pub/memsize.patch There is a bootable -stable picobsd floppy too, for those who don't want to compile a kernel: ftp://sumatra.americantv.com/pub/picobsd.bin -- Jonathan (*) I don't consider FBSDBOOT.EXE a serious objection; it may or may not have worked before, and it may or may not work now. (As discussed to death on earlier threads on this list). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
On May 05, 1999 at 03:38:05AM -0400, Jerry Alexandratos wrote:
Jonathan Lemon jle...@americantv.com says:
:
: Not true. VM86 is also required to support VESA. Also, it is used
: for reliable memory detection (which is why I want to make it mandatory).
: No more My Stinkpad only detected 64M, what do I do now??! questions.
Actually, even with VM86, the kernel still doesn't correctly detect the
StinkPad's memory.
Hm, if that's so, then it's an implementation bug. Can you try the
following patch, boot the system with the -v flag, and mail me back
the result of the dmesg output?
--
Jonathan
Index: i386/i386/vm86.c
===
RCS file: /tuna/ncvs/src/sys/i386/i386/vm86.c,v
retrieving revision 1.25
diff -u -r1.25 vm86.c
--- vm86.c 1999/05/12 21:38:45 1.25
+++ vm86.c 1999/05/19 15:47:10
@@ -41,6 +41,7 @@
#include vm/vm_page.h
#include vm/vm_param.h
+#include sys/reboot.h
#include sys/user.h
#include machine/md_var.h
@@ -524,6 +525,13 @@
*pte = (1 PAGE_SHIFT) | PG_RW | PG_V;
/*
+* use whatever is leftover of the vm86 page layout as a
+* message buffer so we can capture early output.
+*/
+ msgbufinit((vm_offset_t)vm86paddr + sizeof(struct vm86_layout),
+ ctob(3) - sizeof(struct vm86_layout));
+
+ /*
* get memory map with INT 15:E820
*/
#define SMAPSIZsizeof(*smap)
@@ -541,6 +549,13 @@
i = vm86_datacall(0x15, vmf, vmc);
if (i || vmf.vmf_eax != SMAP_SIG)
break;
+ if (boothowto RB_VERBOSE)
+ printf(SMAP type=%02x base=%08x %08x len=%08x %08x\n,
+ smap-type,
+ *(u_int32_t *)((char *)smap-base + 4),
+ (u_int32_t)smap-base,
+ *(u_int32_t *)((char *)smap-length + 4),
+ (u_int32_t)smap-length);
if (smap-type == 0x01 smap-base = highwat) {
*extmem += (smap-length / 1024);
highwat = smap-base + smap-length;
Index: kern/subr_prf.c
===
RCS file: /tuna/ncvs/src/sys/kern/subr_prf.c,v
retrieving revision 1.51
diff -u -r1.51 subr_prf.c
--- subr_prf.c 1998/12/03 04:45:56 1.51
+++ subr_prf.c 1999/03/19 19:10:47
@@ -674,10 +674,24 @@
}
}
+static void
+msgbufcopy(struct msgbuf *oldp)
+{
+ int pos;
+
+ pos = oldp-msg_bufr;
+ while (pos != oldp-msg_bufx) {
+ msglogchar(oldp-msg_ptr[pos], NULL);
+ if (++pos = oldp-msg_size)
+ pos = 0;
+ }
+}
+
void
msgbufinit(void *ptr, size_t size)
{
char *cp;
+ static struct msgbuf *oldp = NULL;
cp = (char *)ptr;
msgbufp = (struct msgbuf *) (cp + size - sizeof(*msgbufp));
@@ -687,7 +701,10 @@
msgbufp-msg_size = (char *)msgbufp - cp;
msgbufp-msg_ptr = cp;
}
+ if (msgbufmapped oldp != msgbufp)
+ msgbufcopy(oldp);
msgbufmapped = 1;
+ oldp = msgbufp;
}
#include opt_ddb.h
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
On May 05, 1999 at 12:27:31PM -0700, Mike Smith wrote: The issue here is that the BIOS will tell us how much memory we are _allowed_to_use_, which is not always the same as the amount of physical memory present in the system. Some memory may be (is sometimes) reserved for use by eg. APM/ACPI. We fare badly at the moment on these systems because we ignore this and use all the memory we can find. Yup. That's probably the problem with the Thinkpads; the code patch I just sent out will dump the ACPI System Address map, so I can figure out what is happening. I bet that it declares one memory range for all the ram, and then overlays a second reserved address on top of it. Right now, I don't handle that correctly. It should be simple to write some code to aggregate this map and fill in the phys_avail[] structure; then the entire memory probe in machdep.c can go away. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
On May 05, 1999 at 05:00:16PM -0700, Carlos C. Tapang wrote: In a nutshell, there is a table of interrupt vectors which is set by the BIOS at boot time, which are used by the loader (and by the FreeBSD kernel, if VM86 is turned on). Thanks, Jonathan. Are any of the following TRUE? 1. FreeBSD is affected by these vectors only if VM86 is turned ON. Um, I would say that is true. Robert Nordier or Mike Smith may want to step in here and correct me as to what the loader is doing, but I think the kernel only uses the interrupt vectors if VM86 is on. 2. If somebody is using VM86, s/he must be using DOSEMU or some other DOS emulator also (I can't think of anything else one would use VM86 for). Not true. VM86 is also required to support VESA. Also, it is used for reliable memory detection (which is why I want to make it mandatory). No more My Stinkpad only detected 64M, what do I do now??! questions. 3. DOSEMU or any other DOS emulator re-initializes the DOS vectors for virtualization. True - ``doscmd'' has a virtual copy of the vectors that it initializes itself, and doesn't use the actual DOS vectors at all. Basically, what I am guessing is that probably we can fix the problem during vm86 or DOSEMU initialization. I am going to enable vm86 on my system and see what happens. Right now I am not experiencing any problems, and that's probably because I do not have vm86 enabled. The problem only comes into play during case 2; where the kernel actually calls the BIOS. The difficulty is that while FBSDBOOT.EXE may work in some cases, it is not guaranteed to work in _all_ cases (which causes a support nightmare). -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
In article local.mail.freebsd-current/006201bea0ae$7e656340$0d787...@apex.tapang you write: Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I would like to fix it, so please describe exactly what the problem is. What do you mean by the need to reboot the system to restore various vectors that DOS destroys? Do you mean that prior to executing the FreeBSD kernel init routines, DOS does something to the loaded area? I'm sorry I can't find any info on this either in the mail threads or in freebsd.org. Probably I'm not looking hard enough, but I believe it would be more efficient to just ask you. In a nutshell, there is a table of interrupt vectors which is set by the BIOS at boot time, which are used by the loader (and by the FreeBSD kernel, if VM86 is turned on). DOS, when it boots, loads itself into memory somewhere, and then changes the interrupt vectors to point to itself. The problem is, when the kernel/loader is loaded by fbsdboot.exe, DOS is overwritten. This results in the interrupt vectors pointing to garbage, which causes bad things (tm) when the they are used. Even if we don't stomp on DOS, I don't quite think that a BIOS call that ends up calling a DOS routine will do the right thing. There isn't any way (AFAIK) to restore the vectors to the original BIOS boot state. You may want to search the archives for vm86 and terry lambert, (IIRC), for some hypothetical solutions that have been proposed for this problem. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In article local.mail.freebsd-current/15359.920308...@critter.freebsd.dk you write: In message 199903011709.jaa48...@vashon.polstra.com, John Polstra writes: In article 31122.920241...@zippy.cdrom.com, Jordan K. Hubbard j...@zippy.cdrom.com wrote: I'd personally be happy with an egcs that just did sensible things with ELF, Me too. We _must_ not let a.out become a ball and chain. We have stressed over and over all along that we were not going to become a dual-object-format OS. That means we _must_ be willing to abandon a.out support for new code. We will keep the legacy a.out libraries for old applications to link against, but we don't have to keep the ability to generate new ones. To do so would hold us back (_is_ holding us back) with very little to show for it. Wouldn't the first logical step be to stop generating the a.out libs in make world, and check in the final version like with the rest of the compat libs ? How about getting profiling working for ELF kernels before before completely abandoning a.out? -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Mar 03, 1999 at 06:02:37AM +0100, Assar Westerlund wrote: Jonathan Lemon jle...@americantv.com writes: How about getting profiling working for ELF kernels before before completely abandoning a.out? There are patches for that in kern/9413 but I haven't got any feedback on them at all. I did try them, they allow the kernel to compile, but they don't seem to work. In particular, the entries made in the flat profile section are all out of whack. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: doscmd broken on current?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Is doscmd working for anyone on current? Here I just get: - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? Start by invoking it with the various debug/trace options. I'd guess that it may be broken by the signal-related changes that were made recently. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP sockets stuck in the CLOSING state
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Before I spend a lot of time hunting this down, I figured it might be worth asking -- is there any particular reason why TCP sockets may be getting stuck in the CLOSING state more often now? Not sure. But here's a tcpdump trace of a socket that ends up in the CLOSING state. (on the host ``cache''). 14:55:49.142607 folly.56982 cache.9000: S 1691420120:1691420120(0) win 16384 mss 1460 (DF) 14:55:49.142663 cache.9000 folly.56982: S 1946461253:1946461253(0) ack 1691420121 win 17520 mss 1460 (DF) 14:55:49.142991 folly.56982 cache.9000: . ack 1 win 17520 (DF) 14:55:49.143384 folly.56982 cache.9000: P 1:188(187) ack 1 win 17520 (DF) 14:55:49.340283 cache.9000 folly.56982: . ack 188 win 17520 (DF) 14:55:50.287660 cache.9000 folly.56982: P 1:1442(1441) ack 188 win 17520 (DF) 14:55:50.484537 cache.9000 folly.56982: . 1442:2902(1460) ack 188 win 17520 (DF) 14:55:50.484552 cache.9000 folly.56982: P 2902:4362(1460) ack 188 win 17520 (DF) 14:55:50.490171 cache.9000 folly.56982: P 4362:4781(419) ack 188 win 17520 (DF) 14:55:50.490369 cache.9000 folly.56982: F 4781:4781(0) ack 188 win 17520 (DF) 14:55:50.492154 folly.56982 cache.9000: . ack 4781 win 17520 (DF) 14:55:50.492160 folly.56982 cache.9000: F 188:188(0) ack 4781 win 17520 (DF) 14:55:50.492229 cache.9000 folly.56982: . ack 189 win 17520 (DF) 14:55:51.490279 cache.9000 folly.56982: . ack 189 win 17520 (DF) Note that I think there are at least two oddities here: 1. the other end (folly) never acks the FIN. The packets at timestamp .492154 and .492160 do not cover the FIN in the sequence space. Yet the host `folly' closes the socket. 2. the end that is stuck in CLOSING (cache) never retransmits the FIN. (The tcpdump extends for about 5 minutes after the last packet, with 0 packets lost). Both machines are running -current from early this week. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
