On Fri, 13 Dec 2002, Nate Lawson wrote:
On Fri, 13 Dec 2002, Julian Elischer wrote:
On Fri, 13 Dec 2002, Peter Wemm wrote:
Julian Elischer wrote:
looking at the code in src/sys/i386/i386/dump_machdep.c,
we see:
78 dumplo = di-mediaoffset + di-mediasize - Maxmem *
At 9:14 PM -0800 2002/12/13, Jimi Thompson wrote:
With the increasing complexity of the internet, this is often a problem for
those who have large internal networks and/or live in Australia. 30 hops
often isn't enough to make to the core DNS. It probably ought to be
extended to something
On Fri, 13 Dec 2002, Ruslan Ermilov wrote:
On Fri, Dec 13, 2002 at 04:41:06PM +0300, Andrey A. Chernov wrote:
On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
Pardon my ignorance here, but the following fragment
returns -1, doesn't it?
#include stdio.h
void
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
On Sat, Dec 14, 2002 at 09:02:40PM +1100, Bruce Evans wrote:
On Fri, 13 Dec 2002, Ruslan Ermilov wrote:
On Fri, Dec 13, 2002 at 04:41:06PM +0300, Andrey A. Chernov wrote:
On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
Pardon my ignorance here, but the following fragment
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
On Sat, 14 Dec 2002, Ruslan Ermilov wrote:
On Sat, Dec 14, 2002 at 09:02:40PM +1100, Bruce Evans wrote:
For ANSI C, the result of the subtraction only depends on the width
of unsigned char. If unsigned char has the same width as int, then
the result is UINT_MAX; otherwise the result is
Could some knowlegable folks review the patch in kern/45994?
http://www.freebsd.org/cgi/query-pr.cgi?pr=45994
Note: I'm talking about the second patch, not the first one.
In the PR the second patch is base64 encoded and not readable.
Here is a decoded version:
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
Well, there are two patches in that PR. I was not able to unpack
the second mime-encoded diff that implements the NOCORE method, which
is the one I think we should use. The described methodology is sound,
though. If someone could email the diff to me I will give it a more
Just call me an idiot. I'm looking it over now :-)
-Matt
:http://www.dellroad.org/dropbox/coredump.diff
:
:Thanks,
:-Archie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
!@#$Q@#$@#$@#$
This is about the 90th time my -current box has become unusable.
First it won't let me installworld because of some signal snafu with
the kernel being too old, then, as usual, IPFW with the new kernel and
old world fails utterly and now the fragging machine
On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
then, as usual, IPFW with the new kernel and
old world fails utterly and now the fragging machine can't access the
Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys.
To Unsubscribe: send mail to [EMAIL
Dear/Beste Johnson,
I read this on the advocacy list.
Tuesday, November 19, 2002, 7:56:44 PM, you wrote:
Support for the 80386 processor has been removed from the GENERIC kernel. The
default FreeBSD kernel is now more optimized for modern CPUs. No longer do
you have to settle for
In message [EMAIL PROTECTED], Alex writes:
Dear/Beste Johnson,
I read this on the advocacy list.
Tuesday, November 19, 2002, 7:56:44 PM, you wrote:
Support for the 80386 processor has been removed from the GENERIC kernel. The
default FreeBSD kernel is now more optimized for modern CPUs. No
Another one:
http://bento.freebsd.org/errorlogs/alpha-5-latest/maildrop-1.5.0.log
Kris
msg48714/pgp0.pgp
Description: PGP signature
Hi Kirk,
Panic message was: Block already free. I had to fsck -y manually,
but nothing special was found and fixed. The machine rebooted over
and over and paniced always at the same place. This shouln't happen
I guess.
#10 0xc02f055b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
:
:On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
: then, as usual, IPFW with the new kernel and
: old world fails utterly and now the fragging machine can't access the
:
:Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys.
How about something like this
I have just right now updated to the -CURRENT branch.
Well unfortunately it appears that apparently remove ssh login to the
freebsd box is failing with the followgin login screen message:
sshd[480]: fatal: ssh_msg_send: write
--
Marcin Dalecki
To Unsubscribe: send mail to [EMAIL
Matthew Dillon wrote:
:
:On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
: then, as usual, IPFW with the new kernel and
: old world fails utterly and now the fragging machine can't access the
:
:Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys.
This was on an x86, 5.0-current as of roughly 8am EST today.
Machine panic'ed when it finished /usr and moved on to /var on
a manually invoked fsck -B (I'd hit ^C to abort multi-user startup
during fsck and was surprised to see the system continue on.. ;)
Drew
panic: ffs_blkfree: freeing free
Support for the 80386 processor has been removed from the GENERIC
kernel. The default FreeBSD kernel is now more optimized for modern
CPUs. No longer do you have to settle for performance draining
compatibility with hardware you haven't owned in a decade.
I don't feel this is a good
:
:I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
:at module load time using a kernel environment variable. Looks to me
:that it would do what you want.
:
:Maxime
No, this isn't what I want. I want something that can be articulated
without having to reboot the
Hello all,
I recently decided that it would be a good idea to set up a diskless
workstation at home. While I was working on setting it up I ran into numerous
problems with the rc scripts, particularly chick-and-egg type mounting
problems. However I also noticed some problems with scripts that
Hi,
I've got an Intel D845EBG2. I have 2 ACPI related problems I'm
looking for advice on:
- ATI Rage 128 Pro TF
If I suspend to S3 from text mode on console, the screen remains blank
after resume. The system is otherwise functional, and can be logged
into remotely.
If I start X after
Dear/Beste phk,
Saturday, December 14, 2002, 10:14:20 PM, you wrote:
In message [EMAIL PROTECTED], Alex writes:
Dear/Beste Johnson,
I read this on the advocacy list.
Tuesday, November 19, 2002, 7:56:44 PM, you wrote:
Support for the 80386 processor has been removed from the GENERIC
hi,
i've just 'make buildworld' 'make buildkernel' on my thinkpad x23,
but cardbus doesn't work.
here is the 'boot -v' message around the cbb,
cbb0: RF5C476 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 3.0 on
pci2
pcib2: device cbb0 requested unsupported memory range 0x0-0x0
Hello all,
I recently during a configuration of a diskless workstation I decided to set up
named to use with the isc-dhcpd3 port. I have configured named to my liking.
Unfortunately when I try to connect using ssh the connection times out because
sshd cannot resolve the name of the connecting
In message [EMAIL PROTECTED], Alex writes:
I don't feel this is a good decision. (I still have a 486, act as a
small server and a 286 witch is in storage) This basally means that
any one who doesn't have the latest processor can't install FreeBSD.
No it doesn't mean that.
FreeBSD still runs
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
It means that you can not install FreeBSD on a 386 unless you have a
486+ machine that can compile a new FreeBSD system and have a way to
get that version to the 386.
Another option is to install 4.x and upgrade to 5.x
--
Best regards/Met vriendelijke groet,
Alex
To Unsubscribe: send mail
Dear/Beste Mark,
Saturday, December 14, 2002, 11:15:24 PM, you wrote:
Support for the 80386 processor has been removed from the GENERIC
kernel. The default FreeBSD kernel is now more optimized for modern
CPUs. No longer do you have to settle for performance draining
compatibility with
Matthew Dillon wrote:
:I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
:at module load time using a kernel environment variable. Looks to me
:that it would do what you want.
No, this isn't what I want. I want something that can be articulated
without
:Now I would really dislike seeing your patch in the tree, since I
:consider it's a rather crude hack to circumvent the ABI problems of
:ipfw. As I've already said to luigi in private e-mail (I would be
:surprised if this hasn't been already discussed in the lists as well),
:the proper way to
:Now I would really dislike seeing your patch in the tree, since I
:consider it's a rather crude hack to circumvent the ABI problems of
:ipfw. As I've already said to luigi in private e-mail (I would be
:surprised if this hasn't been already discussed in the lists as well),
:the proper way
:I disagree with committing this hack; keep it as a local mod if you must.
:
:As to the problem; don't wait for Luigi to fix the ABI problems, do it
:yourself. Good things happen when folks are PO'd and won't settle for the
:status quo.
:
:Sam
I'm sorry you disagree, but it doesn't
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: I don't feel this is a good decision. (I still have a 486, act as a
: small server and a 286 witch is in storage) This basally means that
: any one who doesn't have the latest processor can't install FreeBSD.
:
: No it doesn't
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
John Baldwin [EMAIL PROTECTED] wrote:
On 12-Dec-2002 Kris Kennaway wrote:
I got this on an alpha tonight. It was under heavy load at the time
(18 simultaneous package builds had just been spawned on the machine).
Any ideas?
Slab at 0xfc00042d3fb8, freei 2 = 0.
panic: Duplicate
On Mon, Dec 09, 2002 at 03:11:35PM -0800, Lars Eggert wrote the words in effect of:
With today's -current, after typing reboot into tcsh:
NFS append race @0:13
NFS append race @0:23
NFS append race @0:13
NFS append race @0:3
NFS append race @0:60
NFS append race @0:168
NFS append race
Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
Brian F. Feldman said words to the effect of;
John Baldwin [EMAIL PROTECTED] wrote:
On 12-Dec-2002 Kris Kennaway wrote:
I got this on an alpha tonight. It was under heavy load at the time
(18 simultaneous package builds
:The problem appears to be that swapout_procs() is swapping out a process
:that is in the process of exiting (in exit1()) and having already
:relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be
:preventing the swapout). It's clearly not correct for a process in exit1()
:P_WEXIT is set, so the process won't get swapped out. The problem is that
:the vmspace refcnt is 0 when swapout_procs is called, since it was
:decremented in exit1. The refcnt is incremented before p_flag is tested
:for P_WEXIT, the swapout is skipped because its found to be set, and then
What about something like this. If the vm_refcnt is still being
decremented too early, could it be moved to just before the thread_exit()
call?
-Matt
Index: kern/kern_exit.c
Alex wrote:
Support for the 80386 processor has been removed from the GENERIC
kernel. The default FreeBSD kernel is now more optimized for modern
CPUs. No longer do you have to settle for performance draining
compatibility with hardware you haven't owned in a decade.
I don't feel
Jake Burkholder [EMAIL PROTECTED] wrote:
Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
Brian F. Feldman said words to the effect of;
John Baldwin [EMAIL PROTECTED] wrote:
On 12-Dec-2002 Kris Kennaway wrote:
I got this on an alpha tonight. It was under heavy load at
Matthew Dillon [EMAIL PROTECTED] wrote:
What about something like this. If the vm_refcnt is still being
decremented too early, could it be moved to just before the thread_exit()
call?
The problem that had to be fixed by removing this race was that two
processes with the same
It's a big mess. exit1() sets up vm-vm_freer = p and then
vmspace_exitfree() tests that and calls vmspace_dofree(). It
looks like vm-vm_freer is acting like an exit-lock, so only
one process/thread actually frees the vmspace. But there are
still some serious race conditions.
Here's another go at a patch (untested).
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.187
diff -u -r1.187 kern_exit.c
---
oops, sorry, I blew that patch. exitingcnt would have to be incremented
unconditionally.
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving
Whoop. Ok, here's a new patch. I think this covers all the cases.
I've done some testing and it appears to do the right thing, please
look it over (the last patch had type-o's and didn't cover the correct
cases).
-Matt
Index:
i386:
http://bento.freebsd.org/errorlogs/i386-5-latest/powerpc-rtems-binutils-2.13.log
alpha:
http://bento.freebsd.org/errorlogs/alpha-5-latest/libdivxencore-devel-0.4.0.50.log
sparc64:
http://obsecurity.dyndns.org/errorlogs/libdivxencore-devel-0.4.0.50.log
Hi
After building a system from yesterday's sources (14/12/02), I rebuild
my X server from ports. Upon invoking startx the X server terminated
with the following messages:
Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved.
...
...
/var/log/XFress86.0.log has
I didn't see any warnings in /usr/share/examples/etc/make.conf, so I
thought I'd share my experience with CPUTYPE=p4.
Building world with CPUTYPE=p4 results in static when playing back mpeg
audio. All other audio works fine. A few cases where this is present
(to show it is not application
Joe Kelsey wrote:
/* name must start with a '/' but not contain one. */
if (*name != '/' || len 2 || index(name + 1, '/') != NULL) {
free(ret, M_SEM);
return (EINVAL);
}
The comment makes it
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
Alex wrote:
It means that you can not install FreeBSD on a 386 unless you have a
486+ machine that can compile a new FreeBSD system and have a way to
get that version to the 386.
Yes, this is true. Several of us were annoyed by the change,
which appeared at the time to have been done solely
M. Warner Losh wrote:
One problem with most 386 boxes is that they have very little memory.
sysinstall is a big, bloated pig dog these days that takes more RAM
than most 386 boxes have. This is true also for many 486 boxes too.
So even if 386 stuff were in the default kernel, you'd likely
Sorry for butting in, but my $.02 is that 386's are old enough that
FreeBSD, or any other OS for that matter, shouldn't wait up for them.
They've gotten to the point where they are basically useless except
for running older software, which was likely written for them anyways.
If I had a 386 that I
Hi
If your CURRENT is pretty recent, please add into your /boot/loader.conf
hw.pci.allow_unsupported_io_range=1
and then reboot.
kt
On Sun, Dec 15, 2002 at 07:34:39AM +0900, FUJITA Kazutoshi wrote:
hi,
i've just 'make buildworld' 'make buildkernel' on my thinkpad x23,
but
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
sshd: fatal: ssh_msg_send: write
Timeout before authentication for x.x.x.x
I just cvusped my dev box again to -current.
Someone else on groups.google.com has this problem.
63 matches
Mail list logo
