In article 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-slee
In article 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
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:
&g
In article 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
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 lockmg
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
In article 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 j
In article 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 d
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 p
In article 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
In article 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 Unsubsc
In article [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 en
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 t
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
In article
[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
On Fri, Jul 05, 2002 at 02:38:08AM +1000, Bruce Evans wrote:
> On Thu, 4 Jul 2002, Jonathan Lemon wrote:
>
> > In article
>[EMAIL PROTECTED]> you
>write:
> > >in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> > >path
> >
In article
[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 car
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 ?
> > (I don't care much about the name, just the functionality)
> >
> > #d
What do people think about adding the following macro to ?
(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) && (((t
In article [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
In article [EMAIL PROTECTED]> you write:
>Jeffrey Hsu wrote:
>> Can you try this fix instead? It's based on a similar patch Jonathan Lemon
>> sent to me for a similar spot in tcp_subr.c.
>
>Well yes, this works too, since it produces the same code as with my
>f
In article [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);
1017
In article [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 al
In article [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 w
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.
> :
>
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,
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:
> >
> >MK>hi, there!
> >MK>
> >MK>On Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:
> >MK>
> >MK>> On Wed, Oct 17, 2001 at 12:11:45PM
In article
[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:
In article [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 fx
In article [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/h
In article [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
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.
> > *
>
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
In article
[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.
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:
> >
> >
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 s
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.flug
In article [EMAIL PROTECTED]> you
write:
>Here is a patch I have locally that would be useful for Bill Paul,
>I think. I know, we could use "flag0" for this, but it seems to
>me that this will be an increasingly common option in hadware.
>
>I know Bill had to set this manually as a compile time
In article [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:
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_c
In article [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
In article [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-
In article [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 t
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.
&g
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,
&g
In article [EMAIL PROTECTED]> you write:
>
> I wonder status of KSE, I am dreaming rewrite our application
>server using kqueue+pthread(KSE), current, we use poll()+pthread
>because pthread does not work with kqueue at present.
That's news to me. kqueue + libc_r should work fine in -stable, AF
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),
In article
[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 fix
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
In article [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 i
In article
[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
>T
In article
[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
>T
e 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 b
In article [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 print
In article
[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 incl
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]&g
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
In article [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
In article [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 [EM
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 wai
In article [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:
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
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 chang
On Tue, Apr 18, 2000 at 10:17:36AM -0700, Matthew Dillon wrote:
>
> :In article [EMAIL PROTECTED]> you write:
> :>Now I got lost of
> :>
> :>/usr/include/sys/event.h:159: warning: `struct timespec' declared inside
> :>parameter list.
> :>
> :>because include it.
> :>Please fix somehow.
> :
> :I
In article [EMAIL PROTECTED]> you write:
>Now I got lost of
>
>/usr/include/sys/event.h:159: warning: `struct timespec' declared inside
>parameter list.
>
>because include it.
>Please fix somehow.
I'm looking at this now.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
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 m
In article [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 noth
In article [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 "unsubsc
In article [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
In article [EMAIL PROTECTED]> you write:
>> In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> >> fxp0: The Intel driver is by far the highest preformance model,
>> >> beats the 3com (second best) hands down with much lower CPU
>> >> overhead.
>> >
>> >Do you actually have any numbers to quan
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)
In article 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 :-(
>
In article [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 appropri
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!
> >
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
> ab
On Dec 12, 1999 at 04:00:00PM -0500, Garrett Wollman wrote:
> <<[EMAIL PROTECTED]> said:
>
> > I have NOT tested this fix yet, so I don't know if it works, but I
> > believe the problem is that on high speed networks the milliscond round
> > trip delay is short enough that you can get
In article
[EMAIL PROTECTED]>
you write:
>
>Why is the /dev names ida0?? for the disk when the kernel are trying to
>mount rootdev to id0??? (Guess what... It is'nt compatibel ;)
``ida'' is the name of the controller. ``id'' is the name of the disk.
--
Jonathan
To Unsubscribe: send mail to [
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 [EMAIL PROTECTED]> you
>write
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 change
In article [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 t
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 pro
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
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
> > >
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 i
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
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),
In article [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 th
On Aug 08, 1999 at 09:57:10AM -0700, Mike Smith wrote:
> > > > Fatal trap 9: general protection fault while in kernel mode
> > > > instruction pointer = 0x48:0x8034
> > > > stack pointer = 0x10:0xc0279e98
> > > > frame pointer = 0x10:0x6789
> > > > code segment = base 0xc00f00
On Aug 08, 1999 at 10:20:38PM -0700, Mike Smith wrote:
>
> Jonathan; just some context, this is with your old 16-bit-protmode
> patches, spiffed up for -current, which I committed late last week.
Heh. I had just about forgotten about this patchset. I was somwehat
under the impression it wasn'
In article
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
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 t
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
On May 05, 1999 at 03:38:05AM -0400, Jerry Alexandratos wrote:
> Jonathan Lemon 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 detect
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
In article
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 e
On Mar 03, 1999 at 06:02:37AM +0100, Assar Westerlund wrote:
> Jonathan Lemon 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
&g
In article you
write:
>In message <199903011709.jaa48...@vashon.polstra.com>, John Polstra writes:
>>In article <31122.920241...@zippy.cdrom.com>,
>>Jordan K. Hubbard wrote:
>>>
>>> I'd personally be happy with an egcs that just did sensible things
>>> with ELF,
>>
>>Me too. We _must_ not let
In article [EMAIL PROTECTED]> you
write:
>
>On Sat, Nov 06, 1999 at 12:50:16AM +0100, Ollivier Robert wrote:
>
>A child process seems to be able to let go of a parent's lock on
>4.0 by closing a file discriptor, the same doesn't seem to be true
>on 3.3.
>From the manual page for flock:
NOTES
In article [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 th
In article [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
100 matches
Mail list logo
