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:
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
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
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
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
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 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
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
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
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
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)
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
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
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
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
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
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
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
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));\
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
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,
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
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
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 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
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
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
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
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
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
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
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
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:
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
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:
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
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
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)
] {
] ...
]
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;
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
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
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 "d
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),
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
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
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
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
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
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
...
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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 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
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
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
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 s
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
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
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
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
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
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
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
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)
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
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
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
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.
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.
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
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
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
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
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
90 matches
Mail list logo
