Re: 5.0 showstopper
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 *
(off_t)PAGE_SIZE;
79 dumplo -= sizeof kdh * 2;
80 i = di-dumper(di-priv, kdh, 0, dumplo, sizeof kdh);
81 if (i)
82 printf(\nDump failed writing header (%d)\n, i);
83 dumplo += sizeof kdh;
84 i = 0;
It looks like the following test should go after line 77
if (di-mediasize ((Maxmem * (off_t)PAGE_SIZE) +
(sizeof kdh * 2) + (16*1024)) {
/* 16K is an arbitrary buffer
* in case the swap part is
* the first part
*/
printf(\nDump failed. Partition too small.\n);
return;
}
We used to force a 64K safety buffer for swapon, and I think we also did
64K for dump before the last MI dump code conversion. I'd feel a little
happier if you used 64K here instead of 16K.
I'm happy with 64k.. I just chose 16 arbitrarily because I remembered
that there was SOME safety value but I couldn't remember what it was..
1. Why 2 * kdh (the header size)? I thought there was just one.
2 * kdh is subtracted from dumplo for some reason. I don't know if the
second kdh is just supertitious or an obfuscated way of leaving more space
for metadata or necessary.
2. Excessive parens before compare
These are to obfuscate the code by making readers parse all the parentheses
only to discover that there is nothing special going on -- the expression
is just a * b + c * d + e * f obfuscated to ((a * b) + (c * d) + (e * f)).
3. Extra \n in printf
This is needed in some places (to terminate the dump status output)
the not here or in some of the other places that it is used.
So how about:
/*
* Minimum dumpdev size is Maxmem, dump header,
* and 64k safety margin.
*/
Wording could be improved.
if (di-mediasize Maxmem * (off_t)PAGE_SIZE + sizeof(kdh) +
64 * 1024) {
printf(Dump failed. Partition too small.\n);
Wording could be improved. Most error messages including most of the ones
in this routine, are not terminated by a ..
I tried to get brian to fix this back in October after he fixed the special
case of an empty dump device. The following points don't seem to have been
mentioned in this round:
- negative dumplo's are almost harmless because they cause negative physical
block numbers which the hardware rejects.
- the space needed for metadata is machine-dependent. RELENG_4 leaves
enough space for the label and all sectors before it. Since the i386
MBR is before the label, it gets protected too, even in the dangerously
dedicated case where the MBR is on the same % slice as the dump partition
(and the dump partition is at offset 0). The swapper leaves a fairly
arbitrary and much larger than normally necessary space for metadata
(64K IIRC). But dumping never agreed with swapping about this amount
(64K protects the label from swapping and LABELSECTOR magic protects
the label and much more from dumping).
- dumping is broken similarly on some other arches (ia64's at least).
- checking the bounds at the top level doesn't work in general because
the dump size is not really knwon there (the dump might be sparse, or
compressed...).
My fix for dumping problems was to turn of dumping when it was
second-systemed (actually third-systemed).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: TTL
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 more realistic. The other numbers that I've seen used 64, 128, and 256. We ran into this problem in '96, when I was working at AOL. We had a guy in California who wanted to send e-mail to his friend across the hall, but of course those packets had to traverse the country to be delivered to our servers in Virginia. We went back and forth a few times, and I even set up tcpdump on the particular machine I told him to connect directly to -- I could see his packets coming in, but our responses were never received. Turns out that, by a quirk of routing fate, he was something like 32 hops away, and while his OS was fine, our particular patch revision of HP-UX 9 was hard-coded at 30. We applied a later patch to the machines, and everything went back to normal. This is not a new problem. Unfortunately, many OSes may still have inappropriate values defined. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New AWK bug with collating
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
main(void)
{
int i;
i = (unsigned char)1 - (unsigned char)2;
printf(%d\n, i);
}
It very depends on compiler, i.e. does it implements value preseving or
unsigned preserving for 'char' type conversions. Or ANSI C vs. common C
mode. Better be safe for both.
Read 6.10.1.1 section here:
http://wwwrsphysse.anu.edu.au/doc/DUhelp/AQTLTBTE/DOCU_067.HTM
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 -1. This is an example
of the brokenness of value preserving conversions -- the value is
as far as possible from being preserved.
Then assignment to int i may cause overflow. There is no overflow if
the RHS is -1. If the RHS is UINT_MAX, then the result of the assignment
is implementation-defined. The value is is preserved even less than before.
I think it is usually -0 on 1's complement machines.
So ache's changes is basically a fix for 1's complement machines. I don't
see much point in it, sincw we assume 2's complement in most places in
libc/string (except strcoll() :-). E.g., memcmp() just subtracts the
unsigned char's and assume that all the conversions turn out like they
do on 2's complement machines. We actually use an assembler version of
memcmp on most arches but...
This is handled by the -traditional flag of gcc(1):
: `-traditional'
:
: Attempt to support some aspects of traditional C compilers.
: Specifically:
:
[...]
:
: * Integer types `unsigned short' and `unsigned char' promote to
: `unsigned int'.
With -traditional, the code I quoted still produces -1.
It produces overflow which normally gives -1 on 2's complement machines.
In any case, this section doesn't apply to this case because
no conversion described in section 6.10 is ever done here,
since both operands are of the same type, unsigned char.
Yes it does. The common type (for arithmetic operators like subtraction)
is never smaller than int. Both of the unsigned char operands get
converted to int in the simplest case where unsigned char is smaller
than int. See 6.10.1 (5) and 6.10.1.1 about integral promotions.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 10:08:25 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 04:08:02 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New AWK bug with collating
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
returns -1, doesn't it?
#include stdio.h
void
main(void)
{
int i;
i = (unsigned char)1 - (unsigned char)2;
printf(%d\n, i);
}
It very depends on compiler, i.e. does it implements value preseving or
unsigned preserving for 'char' type conversions. Or ANSI C vs. common C
mode. Better be safe for both.
Read 6.10.1.1 section here:
http://wwwrsphysse.anu.edu.au/doc/DUhelp/AQTLTBTE/DOCU_067.HTM
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 -1. This is an example
of the brokenness of value preserving conversions -- the value is
as far as possible from being preserved.
Then assignment to int i may cause overflow. There is no overflow if
the RHS is -1. If the RHS is UINT_MAX, then the result of the assignment
is implementation-defined. The value is is preserved even less than before.
I think it is usually -0 on 1's complement machines.
So ache's changes is basically a fix for 1's complement machines. I don't
see much point in it, sincw we assume 2's complement in most places in
libc/string (except strcoll() :-). E.g., memcmp() just subtracts the
unsigned char's and assume that all the conversions turn out like they
do on 2's complement machines. We actually use an assembler version of
memcmp on most arches but...
Hmm, then how you could explain the difference between -traditional
and -ansi outputs for the following fragment on i386:
int printf(char *, ...);
int
main(void)
{
long long l;
unsigned char c1 = 1;
unsigned char c2 = 2;
l = c1 - c2;
printf(%lld\n, l);
l = -1;
printf(%lld\n, l);
}
Or the same code but with `long' on sparc64.
This is handled by the -traditional flag of gcc(1):
: `-traditional'
:
: Attempt to support some aspects of traditional C compilers.
: Specifically:
:
[...]
:
: * Integer types `unsigned short' and `unsigned char' promote to
: `unsigned int'.
With -traditional, the code I quoted still produces -1.
It produces overflow which normally gives -1 on 2's complement machines.
In any case, this section doesn't apply to this case because
no conversion described in section 6.10 is ever done here,
since both operands are of the same type, unsigned char.
Yes it does. The common type (for arithmetic operators like subtraction)
is never smaller than int. Both of the unsigned char operands get
converted to int in the simplest case where unsigned char is smaller
than int. See 6.10.1 (5) and 6.10.1.1 about integral promotions.
I stand corrected, thanks for explanations, now I see they do.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg48703/pgp0.pgp
Description: PGP signature
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 16:12:14 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New AWK bug with collating
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 -1. This is an example
of the brokenness of value preserving conversions -- the value is
as far as possible from being preserved.
Hmm, then how you could explain the difference between -traditional
and -ansi outputs for the following fragment on i386:
int printf(char *, ...);
int
main(void)
{
long long l;
unsigned char c1 = 1;
unsigned char c2 = 2;
l = c1 - c2;
printf(%lld\n, l);
l = -1;
printf(%lld\n, l);
}
Or the same code but with `long' on sparc64.
The first paragraph above is all about the ANSI C case. -traditional
gives signedness-preserving conversions, so c1 is prompted to 1U and
c2 is promoted to 2U. 1U - 2U is UINT_MAX on all machines. The
difference between UINT_MAX and -1 can be seen by converting these
values to a common wider type as in your example. UINT_MAX LLONG_MAX
on all machines supported by FreeBSD although not in general, so
assigning it to `l' doesn't change its value.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Request for review: kern/45994
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: http://www.dellroad.org/dropbox/coredump.diff I'm not expert enough in this area to review it alone, but would be happy to commit it if other agree it's suitable. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 10:06:29 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for review: kern/45994
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 complete lookover. -Matt :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: : :http://www.dellroad.org/dropbox/coredump.diff : :I'm not expert enough in this area to review it alone, but would :be happy to commit it if other agree it's suitable. : :Thanks, :-Archie : :__ :Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for review: kern/45994
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
ipfw userland breaks again.
!@#$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 can't access the network which means I can't installworld. So now I have to boot the old kernel, install the new ipfw, then reboot so I can install the new world. I am really getting sick and tired of the ipfw userland breaking every other week. It makes the system unusable when IPFIREWALL_DEFAULT_TO_ACCEPT is not specified in the kernel config. I am going to add an ioctl() that unbreaks the firewall for these cases. ipfw -unbreak or something like that, which doesn't fail whenever someone changes the ipfw kernel interface. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
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 PROTECTED] with unsubscribe freebsd-current in the body of the message
80386 out of GENERIC
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 performance draining compatibility with hardware you haven't owned in a decade. 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. (I could be wrong) Having a option during the installation to use GENERIC or PENTIUM (IV) would be far better. A option to enable/disable hardware compile one own kernel would be great to. I never owned any SCSI devices in a decade. -- Best regards/Met vriendelijke groet, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 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 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 on all 386 family CPUs, the only difference is that if you want to run it on a 80386 you need to enable an option in your kernel config file. It will out of the box run on 486 and anything later. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: More missing perl dependencies
Another one: http://bento.freebsd.org/errorlogs/alpha-5-latest/maildrop-1.5.0.log Kris msg48714/pgp0.pgp Description: PGP signature
Panic with recent CURRENT (1 hour ago)
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 #11 0xc03f9a8a in ffs_blkfree (fs=0xcc27b800, devvp=0xcc284384, bno=370040, size=16384, inum=1400) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771 #12 0xc0408fcf in indir_trunc (freeblks=0xcc586500, dbn=1481056, level=0, lbn=45068, countp=0xe6928c10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2603 #13 0xc0408f94 in indir_trunc (freeblks=0xcc586500, dbn=1480064, level=1, lbn=4108, countp=0xe6928c10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2599 #14 0xc0408a75 in handle_workitem_freeblocks (freeblks=0xcc586500, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2469 #15 0xc0405c9a in process_worklist_item (matchmnt=0x0, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:745 #16 0xc04059e0 in softdep_process_worklist (matchmnt=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:624 #17 0xc034337e in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1749 #18 0xc02dcc14 in fork_exit (callout=0xc0343090 sched_sync, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:872 Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:
: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 (patch enclosed). If there are no
objections I will commit it along with a documentation update, and
maybe also add some RC code give the sysad a chance to ipfw unbreak if
ipfw otherwise fails during the boot sequence.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.18
diff -u -r1.18 ipfw2.c
--- sbin/ipfw/ipfw2.c 26 Nov 2002 22:53:14 - 1.18
+++ sbin/ipfw/ipfw2.c 14 Dec 2002 22:08:11 -
@@ -3307,6 +3307,30 @@
printf(Flushed all %s.\n, do_pipe ? pipes : rules);
}
+static void
+unbreak()
+{
+ if (!do_force !do_quiet) { /* need to ask user */
+ int c;
+
+ printf(Are you sure? [yn] );
+ fflush(stdout);
+ do {
+ c = toupper(getc(stdin));
+ while (c != '\n' getc(stdin) != '\n')
+ if (feof(stdin))
+ return; /* and do not flush */
+ } while (c != 'Y' c != 'N');
+ printf(\n);
+ if (c == 'N') /* user said no */
+ return;
+ }
+ if (setsockopt(s, IPPROTO_IP, IP_FW_UNBREAK, NULL, 0) 0)
+ err(EX_UNAVAILABLE, setsockopt(IP_FW_UNBREAK));
+ if (!do_quiet)
+ printf(Flushed all rules and installed a pass-through.\n);
+}
+
static int
ipfw_main(int ac, char **av)
{
@@ -3398,6 +3422,8 @@
delete(ac, av);
else if (!strncmp(*av, flush, strlen(*av)))
flush();
+ else if (!strncmp(*av, unbreak, strlen(*av)))
+ unbreak();
else if (!strncmp(*av, zero, strlen(*av)))
zero(ac, av);
else if (!strncmp(*av, resetlog, strlen(*av)))
Index: sys/netinet/in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.73
diff -u -r1.73 in.h
--- sys/netinet/in.h29 Oct 2002 16:46:13 - 1.73
+++ sys/netinet/in.h14 Dec 2002 21:32:07 -
@@ -393,6 +393,7 @@
#defineIP_FW_ZERO 53 /* clear single/all firewall counter(s) */
#defineIP_FW_GET 54 /* get entire firewall rule chain */
#defineIP_FW_RESETLOG 55 /* reset logging counters */
+#defineIP_FW_UNBREAK 56 /* flush and install a pass-thru rule */
#defineIP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */
#defineIP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.19
diff -u -r1.19 ip_fw2.c
--- sys/netinet/ip_fw2.c20 Nov 2002 19:07:27 - 1.19
+++ sys/netinet/ip_fw2.c14 Dec 2002 21:41:52 -
@@ -2535,6 +2535,7 @@
break;
case IP_FW_FLUSH:
+ case IP_FW_UNBREAK:
/*
* Normally we cannot release the lock on each iteration.
* We could do it here only because we start from the head all
@@ -2551,6 +2552,22 @@
s = splimp();
free_chain(layer3_chain, 0 /* keep default rule */);
splx(s);
+
+ /*
+* If unbreaking the rulechain, which a sysad may have to do
+* if IP_FW_ADD fails due to a userland/kernelland mismatch,
+* install a pass-through rule.
+*/
+ if (sopt-sopt_name == IP_FW_UNBREAK) {
+ rule = (struct ip_fw *)rule_buf; /* XXX do a malloc */
+ bzero(rule, sizeof(*rule));
+ rule-rulenum = 2;
+ rule-cmd_len = 1;
+ rule-set = 1;
+ rule-cmd[0].len = 1;
+ rule-cmd[0].opcode = O_ACCEPT;
+ error = add_rule(layer3_chain, rule);
+ }
break;
case IP_FW_ADD:
Index: sys/netinet/raw_ip.c
===
RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.107
diff -u -r1.107 raw_ip.c
--- sys/netinet/raw_ip.c20 Nov 2002 19:00:54 - 1.107
+++ sys/netinet/raw_ip.c14 Dec 2002 21:33:58 -
@@ -399,6 +399,7 @@
SSHD login problems
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 PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
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. How about something like this (patch enclosed). If there are no objections I will commit it along with a documentation update, and maybe also add some RC code give the sysad a chance to ipfw unbreak if ipfw otherwise fails during the boot sequence. 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic in background fsck
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 block
syncing disks, buffers remaining... panic: bremfree: bp 0xce3e35a8 not locked
Uptime: 6m38s
Dumping 511 MB
ata0: resetting devices ..
done
[CTRL-C to abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224
240 256 272 288 304[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 320 336 352
368 384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc024bc45 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc024be93 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc028c2a7 in bremfree (bp=0xce3e35a8) at /usr/src/sys/kern/vfs_bio.c:632
#4 0xc0214f91 in spec_fsync (ap=0xdcb103c4)
at /usr/src/sys/fs/specfs/spec_vnops.c:465
#5 0xc0214428 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#6 0xc0317eb7 in ffs_sync (mp=0xc3f2b000, waitfor=2, cred=0xc1263e80,
td=0xc0402c20) at vnode_if.h:612
#7 0xc02a018b in sync (td=0xc0402c20, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8 0xc024b88c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#9 0xc024be93 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#10 0xc03007ca in ffs_blkfree (fs=0xc3f69000, devvp=0xc3f8b708, bno=7713464,
size=16384, inum=3) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771
#11 0xc030fef1 in indir_trunc (freeblks=0xc1b27a00, dbn=22201312, level=1,
lbn=4108, countp=0xdcb105f0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2603
#12 0xc030f99e in handle_workitem_freeblocks (freeblks=0xc1b27a00, flags=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2469
#13 0xc030cbbd in process_worklist_item (matchmnt=0xc3f2b200, flags=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:745
#14 0xc030c900 in softdep_process_worklist (matchmnt=0xc3f2b200)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:624
#15 0xc030ce82 in softdep_flushworklist (oldmnt=0xc3f2b200, countp=0xdcb10704,
td=0xc4115540) at /usr/src/sys/ufs/ffs/ffs_softdep.c:838
#16 0xc0317e09 in ffs_sync (mp=0xc3f2b200, waitfor=1, cred=0xc4303800,
td=0xc4115540) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1168
#17 0xc02a8b90 in vfs_write_suspend (mp=0xc3f2b200)
at /usr/src/sys/kern/vfs_vnops.c:1020
#18 0xc0306e20 in ffs_snapshot (mp=0xc3f2b200, snapfile=---Can't read userspace from
dump, or kernel process---
)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:312
#19 0xc0315f28 in ffs_mount (mp=0xc3f2b200, path=0xc1b2d080 /var, data=0x0,
ndp=0xdcb10bec, td=0xc4115540) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:297
#20 0xc029848a in vfs_mount (td=0xc4115540, fstype=0xc3f7f100 ,
fspath=0xc1b2d080 /var, fsflags=-592376852, fsdata=0x0)
at /usr/src/sys/kern/vfs_mount.c:1060
#21 0xc0297c18 in mount (td=0x0, uap=0xdcb10d10)
at /usr/src/sys/kern/vfs_mount.c:818
#22 0xc036f7ce in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077938028, tf_ebp =
-1077938152, tf_isp = -592376460, tf_ebx = 135001510, tf_edx = 19, tf_ecx = 135001344,
tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134571915, tf_cs = 31, tf_eflags =
514, tf_esp = -1077938468, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#23 0xc035fa6d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 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. (I could be wrong) Having a option during the installation to use GENERIC or PENTIUM (IV) would be far better. A option to enable/disable hardware compile one own kernel would be great to. I never owned any SCSI devices in a decade. Be careful that you are not asking for something that is too one-sided. FreeBSD-CURRENT is aimed at the bleeding edge. The fact that it runs AT ALL on your hardware is GOOD. _However_, FreeBSD is not going to let CURRENT be held back to some low denominator that is no longer commercially available. Support has only been dropped for the _default_ install. You can still build a custom kernel for 80386. You are in the minority. You have a way to run FreeBSD-CURRENT, you just don't have it in the default install. :-) M -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: :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 whole system. The last time this happened to me, which was today, I had to reboot the system FIVE times before I got the network working again. For example, I tried rebooting into an old kernel and the fragging boot code tried to load the new kernel's ACPI module (actually it tried to load BOTH the old and new kernel's ACPI modules), and it panic'd of course. It took five attempts before I managed to get something that worked with the network up and then I had to reboot *AGAIN* to do the installworld with the new kernel. It's beginning to feel like a windows install! When you are sitting at a boot prompt and have no access to manual pages and such, and no in-boot-help that's significant enough to be worthwhile, it's no help tearing your hair out trying to remember the name of the stupid boot variable. The last thing I want is yet another undocumented or hard-to-find boot variable. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rcng script bugs
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 are important
to everyone, not just diskless users.
/etc/rc.d/named:
The pid file used by the rc script uses the file /var/run/named.pid for use
in reloading, restarting, etc. The default named.conf file in /etc/namedb
contains explicitly sets the pid file to /var/run/named/pid. I assume that the
reason FreeBSD puts the pid file in /var/run/named instead of just /var/run is
because of permissions (the default rc configuration starts named with '-u bind
-g bind') and thus could not write to /var/run. I propose the following change
to /etc/rc.d/named
17c17
pidfile=/var/run/${name}.pid
---
pidfile=/var/run/${name}/pid
in order to match the default named.conf file.
/etc/rc.d/network1:
When using a diskless configuration this file took the interface offline,
preventing the machine from booting. I noticed that a change has been added to
check if an interface is up and skip configuring it if it is. Instead of using
grep it is possible to use ifconfig's -d option (see man page) to only list
interfaces marked as down. This is my change for /etc/rc.d/network1
140c140
network_interfaces=`ifconfig -l -d`
---
network_interfaces=`ifconfig -l`
148a149,153
if ifconfig ${ifn} | grep -s UP, /dev/null 21; then
# Interface is already up, so ignore it.
continue;
fi
Hope this helps someone.
regards,
Galen Sampson
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
secondary ACPI problems
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 resume, the system locks solid. If I suspend from inside X, the system locks solid a few seconds after resume. I'm happy to replace the ATI with something which works. So.. is there a cheap AGP4x video card (to drive analog LCD 1280x1024@60Hz) which is known to work well with ACPI on FreeBSD? - rp.ko If I suspend to S3 and resume, the system becomes nearly unusable because it spends all its time in swi6: tty:sio clock (200%, in fact!:) Ping times go from 3ms to 11000ms from nearby powerbook. Commands take seconds to echo, etc. This does not happen if I do not have rp.ko loaded. I suspect that the rocketport card needs some setup when power is restored. It polls all its ports, so it makes sense that a swi would get clogged. I thought it might be sufficent to unload the driver and reload after resume. However, it doens't appear to be unloadable now. Before I get too far into this, will unloading rp and reloading it suffice, or is there a better way which could just allow me to save and restore the card state so I wouldn't have to reload it on resume? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re[2]: 80386 out of GENERIC
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 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 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 on all 386 family CPUs, the only difference is that if you want to run it on a 80386 you need to enable an option in your kernel config file. It will out of the box run on 486 and anything later. 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. My assumption was for such case. Lets say a home user with a pentium II with Windows 98 and his old 386 as a FreeBSD server. -- Best regards/Met vriendelijke groet, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cbb attach failed
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 (decoding 0xc020-0xcfff, 0xe800-0xf00f) cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 cbb0: RF5C476 PCI-CardBus Bridge mem 0x5010-0x50100fff irq 11 at device 3.1 on pci2 pcib2: device cbb0 requested unsupported memory range 0x0-0x0 (decoding 0xc020-0xcfff, 0xe800-0xf00f) cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 any suggestion? regards, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
named timeouts on localhost
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 host. If I log into the machine running named I found that if I type nslookup I get nameserver timeouts. If I type nslookup on another machine on the network (which uses the machine in question as its nameserver) all queries work exactly as expected. When I run tcpdump -i lo0 I find that the queries are sent. Named logs the query (query loggin is turned on) so I know named recieves the queries. Unfortunately named never responds. I do have a filewall (ipfw), but I flushed all rules, and looked at 'ipfw show' before and after a query to localhost and no packets are denied. I am stumped. Any information on debugging the problem, contacting the correct people, etc. really appreciated. regards, Galen Sampson __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Re[2]: 80386 out of GENERIC
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 on all 386 family CPUs, the only difference is that if you want to run it on a 80386 you need to enable an option in your kernel config file. It will out of the box run on 486 and anything later. 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. Too bad. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 22:09:33 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re[3]: 80386 out of GENERIC
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 to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re[2]: 80386 out of GENERIC
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 hardware you haven't owned in a decade. 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. (I could be wrong) Having a option during the installation to use GENERIC or PENTIUM (IV) would be far better. A option to enable/disable hardware compile one own kernel would be great to. I never owned any SCSI devices in a decade. Be careful that you are not asking for something that is too one-sided. I didn't. I asked for something that is many-sided; at leas for as far processors are concerned. (Its a point of view) FreeBSD-CURRENT is aimed at the bleeding edge. The fact that it runs AT ALL on your hardware is GOOD. _However_, FreeBSD is not going to let CURRENT be held back to some low denominator that is no longer commercially available. I got the impressions that it was here to stay. If it comes back when current becomes stable, then you should consider my opinion as not spoken out. You are in the minority. You have a way to run FreeBSD-CURRENT, you just don't have it in the default install. :-) These though really aren't for me. My most powerful PC is a Pentium 133 MHz. Its not impossible to get around. -- Best regards/Met vriendelijke groet, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
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 having to reboot the whole system. You don't need to reboot with this patch. As I already said it, it's a *module load time* tunable. So if you use ipfw as a module, it will do what you want. If you don't, it's of course useless. 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 fix this problem is to separate the kernel and userland structures of ipfw, and add versioning to the struct. This can be done without even breaking the ABI again, since several pointers in the kernel structures are useless to userland (like the next field) and can be reused to implement structure versioning. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: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 fix this problem is to separate the kernel and :userland structures of ipfw, and add versioning to the struct. : :This can be done without even breaking the ABI again, since several :pointers in the kernel structures are useless to userland (like the next :field) and can be reused to implement structure versioning. : :Cheers, :Maxime If/when Luigi fixes the ABI problems with IPFW, we can remove this 'hack'. Until then, I do not consider the hackiness nature of the patch sufficient reason to not put it in. I've been bitten by this problem dozens of times, and wasted many hours simply because I couldn't get the damn network working, and so have others. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: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 fix this problem is to separate the kernel and :userland structures of ipfw, and add versioning to the struct. : :This can be done without even breaking the ABI again, since several :pointers in the kernel structures are useless to userland (like the next :field) and can be reused to implement structure versioning. : :Cheers, :Maxime If/when Luigi fixes the ABI problems with IPFW, we can remove this 'hack'. Until then, I do not consider the hackiness nature of the patch sufficient reason to not put it in. I've been bitten by this problem dozens of times, and wasted many hours simply because I couldn't get the damn network working, and so have others. 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
: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 change my position. I am not in the business of rewriting other people's APIs. If it means so much to you, YOU go and fix it. No? Then don't complain about my fix. It's no skin off your nose and it will prevent a lot of future headaches, especially if the RC system makes it nice and friendly. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 mean that. : : FreeBSD still runs on all 386 family CPUs, the only difference is that : if you want to run it on a 80386 you need to enable an option in : your kernel config file. : : It will out of the box run on 486 and anything later. 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 have other issues in making sysinstall work and have to do custom hacking... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 16:07:11 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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 free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db I have seen this on a couple of different arch's I think. A vmspace shouldn't be free'd here, it's refcount should not be that low. I wonder if something is free'ing the vmspace w/o dropping the refcount? 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() to be swapped out, and the vmspace _needs_ to be decremented in the correct place or resources are NEVER freed when the race is lost. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS-related panic on reboot
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 @0:518
Stopping cron.
Stopping inetd.
Shutting down daemon processes:.
Shutting down local daemons:.
Writing entropy file:.
[1] Terminated
.
[... snipped ...]
Stopped at nfs_removerpc+0x19: movl0x168(%eax),%eax
db trace
nfs_removerpc(c74675dc,c6b5ce6c,c,c6b0fc00,0) at nfs_removerpc+0x19
nfs_removeit(c6b5ce60,0,c6b0fc00,c21b19a0,1) at nfs_removeit+0x30
nfs_inactive(df0c0aa4,12,c21b19a0,c21b19a0,0) at nfs_inactive+0x8d
[... snipped ...]
Hi.
This problem, is happening (possibly) because nfs_removerpc() is passed a
NULL struct thread (a No No iirc) by nfs_removeit(). nfs_removerpc()
is only called from two places: nfs_removeit() and nfs_remove():
In the case of nfs_remove(), it passes the thread from the
struct compnonentname (cnp-cn_thread), while nfs_removeit() passes
NULL. The problem with this is, that nfs_removeit() passes the thread arg
to nfsm_request(), and it dies.
Could you try the following patch, if you are still getting this
problem:
%%%
Index: nfs_vnops.c
===
RCS file: /home/hiten/ncvs/src/sys/nfsclient/nfs_vnops.c,v
retrieving revision 1.189
diff -u -r1.189 nfs_vnops.c
--- nfs_vnops.c 11 Oct 2002 14:58:32 - 1.189
+++ nfs_vnops.c 14 Dec 2002 16:25:14 -
@@ -1468,7 +1468,7 @@
{
return (nfs_removerpc(sp-s_dvp, sp-s_name, sp-s_namlen, sp-s_cred,
- NULL));
+ curthread));
}
/*
%%%
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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 had just been spawned on the machine). Any ideas? Slab at 0xfc00042d3fb8, freei 2 = 0. panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db I have seen this on a couple of different arch's I think. A vmspace shouldn't be free'd here, it's refcount should not be that low. I wonder if something is free'ing the vmspace w/o dropping the refcount? 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() to be swapped out, and the vmspace _needs_ to be decremented in the correct place or resources are NEVER freed when the race is lost. 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 vmspace_free is called which decrements the refcnt to 0 and prematurely frees the vmspace. Decrementing the refcnt in exit1 breaks the normal refernce count semantics because the vmspace is not being freed then. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
: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() :to be swapped out, and the vmspace _needs_ to be decremented in the correct :place or resources are NEVER freed when the race is lost. : :-- :Brian Fundakowski Feldman \'[ FreeBSD ]''\ : [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ P_WEXIT is set before the vmspace is released. It may be sufficient to have swapout_procs() ignore processes with P_WEXIT set. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
: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 :vmspace_free is called which decrements the refcnt to 0 and prematurely :frees the vmspace. Decrementing the refcnt in exit1 breaks the normal :refernce count semantics because the vmspace is not being freed then. : :Jake Yup, I see it. We could just move the P_WEXIT test but I wonder how many other places the vmspace might be bumped and then released. The real bug appears to be in exit1(). I seem to recall we hit this situation a few months ago. I thought it had been fixed. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.187
diff -u -r1.187 kern_exit.c
--- kern/kern_exit.c10 Dec 2002 02:33:44 - 1.187
+++ kern/kern_exit.c15 Dec 2002 01:08:21 -
@@ -288,7 +288,7 @@
* Can't free the entire vmspace as the kernel stack
* may be mapped within that space also.
*/
- if (--vm-vm_refcnt == 0) {
+ if (vm-vm_refcnt == 1) {
if (vm-vm_shm)
shmexit(p);
vm_page_lock_queues();
@@ -298,7 +298,9 @@
(void) vm_map_remove(vm-vm_map, vm_map_min(vm-vm_map),
vm_map_max(vm-vm_map));
vm-vm_freer = p;
+ KASSERT(vm-vm_refcnt == 1, (expected vm_refcnt of 1));
}
+ --vm-vm_refcnt;
sx_xlock(proctree_lock);
if (SESS_LEADER(p)) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 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. (I could be wrong) Having a option during the installation to use GENERIC or PENTIUM (IV) would be far better. A option to enable/disable hardware compile one own kernel would be great to. I never owned any SCSI devices in a decade. Since people here seems a bit touchy on this subject, I'll try to explain it to you. Today's world is one of plugplay devices (of the real type, not that ISA backwards-compatible sham), devices that can come and go (like cardbus and usb), of systems that can control fan speed, enter stand by, sleep and hibernate modes then come back. It is a world where 4 Gb RAM suddenly seems like just a slightly heavier lower-end server, where we count the days 'till Tb hard disks, and make do until then with RAID devices. A world of SMP, and highly sophisticated processors. Well, 80386 was the first step in this direction, and there was much that was left out of it, which people realized later would be needed. It got to a point that supporting 386 implied huge performance penalties for the rest of the ia32 line (and SMP was out of question altogether). Not only that, but 386 was by and large based on ISA devices, and *those* are also out of the window as we expect devices to identify themselves, and negotiate the resources they'll be using. Not only 5.0 GENERIC kernel does not have support for 386, but it also won't play nice at all with old ISA devices. It is not a matter of simply supporting them. They were _hampering_ all other stuff. So we still support them. Just not where they'll get in the way of the newer stuff. But, to be entirely honest, what would someone want with 5.0 on a 386? You go take a look at the new features of FreeBSD 5.0-R, and try to find any that will be of any use on such a system. ACPI, devfs, SMPng, new software RAID system, support for crypto hardware... I'm sorry, but a 386 just won't be able to take advantage of those things. There is really little point in installing 5.0 on a 386, unless you are one of those who _need_ to have the latest. And, if that's the case, then what would you be doing with a 386? :-) Even on the embedded systems market the 386 has passed away. So, when we throw all those things together, the benefits of kicking 386 out of GENERIC far surpass the possible backlash of angry/disappointed 386 owners. And FreeBSD has always carried the flag of taking most benefit of current hardware. There are other operating systems out there that take great pleasure in supporting more obscure hardware (and, yes, 386 is obscure nowadays). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Fundamentalist Debianites, core children of the Linuxen sounds like it could come from the Book of Mormon, or Tolkien on a bad day... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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 the time (18 simultaneous package builds had just been spawned on the machine). Any ideas? Slab at 0xfc00042d3fb8, freei 2 = 0. panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db I have seen this on a couple of different arch's I think. A vmspace shouldn't be free'd here, it's refcount should not be that low. I wonder if something is free'ing the vmspace w/o dropping the refcount? 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() to be swapped out, and the vmspace _needs_ to be decremented in the correct place or resources are NEVER freed when the race is lost. 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 vmspace_free is called which decrements the refcnt to 0 and prematurely frees the vmspace. Decrementing the refcnt in exit1 breaks the normal refernce count semantics because the vmspace is not being freed then. There are no normal reference count semantics; exit1() attempts to free parts of the vmspace. Sounds to me like a simple solution is to check for P_WEXIT both before and after incrementing the vmspace refcount. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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 vmspace can exit at the same time, and the
vm_refcnt could be 2 the entire time, so neither would perform the current
if (--vm-vm_refcnt == 0) { block.
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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. If two thread go into exit1() at the same time, but vmspace_exitfree() is called in the reverse order, so the first call to vmspace_exitfree() winds up freeing the vmspace, the first process's vmspace might be ripped out from under it. On the flip side if several threads go into exit1() at the same time the vmspace's ref count may never be seen to be '0' if we move the decrement to later on in the code. So my 'what if we did this' patch will fix one problem and create another. The reference count must be decremented where it is currently being decremented in exit1() or there is a chance that multiple exit1()'s will not see the ref count drop to 0 (or be equal to 1). On the flip side (again), vmspace_exitfree() really should not call vmspace_dofree() unless it is the last process, which is not necessarily the same process that detected the ref count going to 0 in exit1(). It's like we need a second ref count field for the vmspace structure, one to determine when the initial bunch of garbage can be freed up (sysV shared memory and usch), and another to determine when vmspace_dofree() can actually be called. -Matt :There are no normal reference count semantics; exit1() attempts to free :parts of the vmspace. Sounds to me like a simple solution is to check for :P_WEXIT both before and after incrementing the vmspace refcount. : :-- :Brian Fundakowski Feldman \'[ FreeBSD ]''\ : [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
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
--- kern/kern_exit.c10 Dec 2002 02:33:44 - 1.187
+++ kern/kern_exit.c15 Dec 2002 01:36:35 -
@@ -289,6 +289,7 @@
* may be mapped within that space also.
*/
if (--vm-vm_refcnt == 0) {
+ ++vm-vm_exitingcnt;
if (vm-vm_shm)
shmexit(p);
vm_page_lock_queues();
@@ -297,7 +298,6 @@
vm_page_unlock_queues();
(void) vm_map_remove(vm-vm_map, vm_map_min(vm-vm_map),
vm_map_max(vm-vm_map));
- vm-vm_freer = p;
}
sx_xlock(proctree_lock);
Index: vm/vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.273
diff -u -r1.273 vm_map.c
--- vm/vm_map.c 1 Dec 2002 18:57:56 - 1.273
+++ vm/vm_map.c 15 Dec 2002 01:40:39 -
@@ -258,7 +258,7 @@
vm-vm_map.pmap = vmspace_pmap(vm); /* XXX */
vm-vm_refcnt = 1;
vm-vm_shm = NULL;
- vm-vm_freer = NULL;
+ vm-vm_exitingcount = 0;
return (vm);
}
@@ -304,7 +304,7 @@
if (vm-vm_refcnt == 0)
panic(vmspace_free: attempt to free already freed vmspace);
- if (--vm-vm_refcnt == 0)
+ if (--vm-vm_refcnt == 0 vm-vm_exitingcount == 0)
vmspace_dofree(vm);
}
@@ -314,9 +314,10 @@
struct vmspace *vm;
GIANT_REQUIRED;
- if (p == p-p_vmspace-vm_freer) {
- vm = p-p_vmspace;
- p-p_vmspace = NULL;
+ vm = p-p_vmspace;
+ p-p_vmspace = NULL;
+ if (--vm-vm_exitingcount == 0) {
+ KASSERT(vm-vm_refcnt == 0, (vm_refcnt was not 0));
vmspace_dofree(vm);
}
}
Index: vm/vm_map.h
===
RCS file: /home/ncvs/src/sys/vm/vm_map.h,v
retrieving revision 1.92
diff -u -r1.92 vm_map.h
--- vm/vm_map.h 22 Sep 2002 04:33:43 - 1.92
+++ vm/vm_map.h 15 Dec 2002 01:38:29 -
@@ -219,7 +219,7 @@
caddr_t vm_daddr; /* (c) user virtual address of data */
caddr_t vm_maxsaddr;/* user VA at max stack growth */
#definevm_endcopy vm_freer
- struct proc *vm_freer; /* vm freed on whose behalf */
+ int vm_exitingcnt; /* several processes zombied in exit1 */
};
#ifdef _KERNEL
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
(lots of posts today Matt!) Re: UMA panic under load
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 revision 1.187
diff -u -r1.187 kern_exit.c
--- kern/kern_exit.c10 Dec 2002 02:33:44 - 1.187
+++ kern/kern_exit.c15 Dec 2002 01:42:12 -
@@ -288,6 +288,7 @@
* Can't free the entire vmspace as the kernel stack
* may be mapped within that space also.
*/
+ ++vm-vm_exitingcnt;
if (--vm-vm_refcnt == 0) {
if (vm-vm_shm)
shmexit(p);
@@ -297,7 +298,6 @@
vm_page_unlock_queues();
(void) vm_map_remove(vm-vm_map, vm_map_min(vm-vm_map),
vm_map_max(vm-vm_map));
- vm-vm_freer = p;
}
sx_xlock(proctree_lock);
Index: vm/vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.273
diff -u -r1.273 vm_map.c
--- vm/vm_map.c 1 Dec 2002 18:57:56 - 1.273
+++ vm/vm_map.c 15 Dec 2002 01:40:39 -
@@ -258,7 +258,7 @@
vm-vm_map.pmap = vmspace_pmap(vm); /* XXX */
vm-vm_refcnt = 1;
vm-vm_shm = NULL;
- vm-vm_freer = NULL;
+ vm-vm_exitingcount = 0;
return (vm);
}
@@ -304,7 +304,7 @@
if (vm-vm_refcnt == 0)
panic(vmspace_free: attempt to free already freed vmspace);
- if (--vm-vm_refcnt == 0)
+ if (--vm-vm_refcnt == 0 vm-vm_exitingcount == 0)
vmspace_dofree(vm);
}
@@ -314,9 +314,10 @@
struct vmspace *vm;
GIANT_REQUIRED;
- if (p == p-p_vmspace-vm_freer) {
- vm = p-p_vmspace;
- p-p_vmspace = NULL;
+ vm = p-p_vmspace;
+ p-p_vmspace = NULL;
+ if (--vm-vm_exitingcount == 0) {
+ KASSERT(vm-vm_refcnt == 0, (vm_refcnt was not 0));
vmspace_dofree(vm);
}
}
Index: vm/vm_map.h
===
RCS file: /home/ncvs/src/sys/vm/vm_map.h,v
retrieving revision 1.92
diff -u -r1.92 vm_map.h
--- vm/vm_map.h 22 Sep 2002 04:33:43 - 1.92
+++ vm/vm_map.h 15 Dec 2002 01:38:29 -
@@ -219,7 +219,7 @@
caddr_t vm_daddr; /* (c) user virtual address of data */
caddr_t vm_maxsaddr;/* user VA at max stack growth */
#definevm_endcopy vm_freer
- struct proc *vm_freer; /* vm freed on whose behalf */
+ int vm_exitingcnt; /* several processes zombied in exit1 */
};
#ifdef _KERNEL
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Patch #3 Re: UMA panic under load
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: 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
--- kern/kern_exit.c10 Dec 2002 02:33:44 - 1.187
+++ kern/kern_exit.c15 Dec 2002 01:45:15 -
@@ -287,7 +287,15 @@
* Need to do this early enough that we can still sleep.
* Can't free the entire vmspace as the kernel stack
* may be mapped within that space also.
+*
+* Processes sharing the same vmspace may exit in one order, and
+* get cleaned up by vmspace_exit() in a different order. The
+* last exiting process to reach this point releases as much of
+* the environment as it can, and the last process cleaned up
+* by vmspace_exit() (which decrements exitingcnt) cleans up the
+* remainder.
*/
+ ++vm-vm_exitingcnt;
if (--vm-vm_refcnt == 0) {
if (vm-vm_shm)
shmexit(p);
@@ -297,7 +305,6 @@
vm_page_unlock_queues();
(void) vm_map_remove(vm-vm_map, vm_map_min(vm-vm_map),
vm_map_max(vm-vm_map));
- vm-vm_freer = p;
}
sx_xlock(proctree_lock);
Index: vm/vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.273
diff -u -r1.273 vm_map.c
--- vm/vm_map.c 1 Dec 2002 18:57:56 - 1.273
+++ vm/vm_map.c 15 Dec 2002 02:05:13 -
@@ -258,7 +258,7 @@
vm-vm_map.pmap = vmspace_pmap(vm); /* XXX */
vm-vm_refcnt = 1;
vm-vm_shm = NULL;
- vm-vm_freer = NULL;
+ vm-vm_exitingcnt = 0;
return (vm);
}
@@ -304,7 +304,7 @@
if (vm-vm_refcnt == 0)
panic(vmspace_free: attempt to free already freed vmspace);
- if (--vm-vm_refcnt == 0)
+ if (--vm-vm_refcnt == 0 vm-vm_exitingcnt == 0)
vmspace_dofree(vm);
}
@@ -314,11 +314,22 @@
struct vmspace *vm;
GIANT_REQUIRED;
- if (p == p-p_vmspace-vm_freer) {
- vm = p-p_vmspace;
- p-p_vmspace = NULL;
+ vm = p-p_vmspace;
+ p-p_vmspace = NULL;
+
+ /*
+* cleanup by parent process wait()ing on exiting child. vm_refcnt
+* may not be 0 (e.g. fork() and child exits without exec()ing).
+* exitingcnt may increment above 0 and drop back down to zero
+* several times while vm_refcnt is held non-zero. vm_refcnt
+* may also increment above 0 and drop back down to zero several
+* times while vm_exitingcnt is held non-zero.
+*
+* The last wait on the exiting child's vmspace will clean up
+* the remainder of the vmspace.
+*/
+ if (--vm-vm_exitingcnt == 0 vm-vm_refcnt == 0)
vmspace_dofree(vm);
- }
}
/*
Index: vm/vm_map.h
===
RCS file: /home/ncvs/src/sys/vm/vm_map.h,v
retrieving revision 1.92
diff -u -r1.92 vm_map.h
--- vm/vm_map.h 22 Sep 2002 04:33:43 - 1.92
+++ vm/vm_map.h 15 Dec 2002 01:47:49 -
@@ -218,8 +218,8 @@
caddr_t vm_taddr; /* (c) user virtual address of text */
caddr_t vm_daddr; /* (c) user virtual address of data */
caddr_t vm_maxsaddr;/* user VA at max stack growth */
-#definevm_endcopy vm_freer
- struct proc *vm_freer; /* vm freed on whose behalf */
+#definevm_endcopy vm_exitingcnt
+ int vm_exitingcnt; /* several processes zombied in exit1 */
};
#ifdef _KERNEL
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
GCC ICEs
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 http://obsecurity.dyndns.org/errorlogs/outguess-0.2.log kris msg48750/pgp0.pgp Description: PGP signature
X server problem - undefined symbols
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 something like: (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Not loading .rodata.str1.32 Not loading .rodata.str1.1 Not loading .rodata.cst8 and so on. After an Internet search, I recompiled the server with -fno-merge-constants and the X server is now running. -- Regards Peter As always the organisation disavows knowledge of this email To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CPUTYPE=p4 warning needed
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 specific): 1) playing an mp3 with mpg123 2) playing an mp3 with xmms 3) playing a movie with mpeg audio in mplayer A symptom of this problem in xmms is that the spectrum analyzer is almost constantly maxed out at most every frequency. Thus, it seems that in the decoding of the audio stream the amplitude of the signal is outputed too high, resulting in some form of clipping. This clipping sounds like static. This is ignorant speculation, but maybe it will help. This problem is present when these applications are installed via packages or compiled from ports. In any case, I think it would be a good idea to include a warning in /usr/share/examples/etc/make.conf that says CPUTYPE optimizations may result in broken code. Maybe it's just my machine, but I've recompiled several times now and it's consistent (if and only if I build and install world with CPUTYPE=p4 is the problem evident). Jon Noack dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Dec 14 20:48:25 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COMPGEEK Preloaded elf kernel /boot/kernel/kernel at 0xc04ff000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04ff0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2539102024 Hz CPU: Pentium 4 (2539.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536805376 (511 MB) avail memory = 516071424 (492 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT AMIINI09 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Using $PIR table, 15 entries at 0xc00f7450 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82850 host to AGP bridge mem 0xe800-0xebff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xdc00-0xdc1f irq 10 at device 29.0 on pci0 usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft Wheel Mouse Optical\M-., rev 1.10/1.21, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 3 uhub1: 3 ports with 3 removable, self powered uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0xd800-0xd81f irq 9 at device 29.1 on pci0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0xd400-0xd41f irq 9 at device 29.2 on pci0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: serial bus, USB at device 29.7 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: PCI-PCI bridge at device 2.0 on pci2 pci3: PCI bus on pcib3 asr0: Adaptec Caching SCSI RAID mem 0xe200-0xe3ff irq 11 at device 2.1 on pci2 asr0: major=154 asr0: ADAPTEC 2100S FW Rev. 370F, 1 channel, 256 CCBs, Protocol I2O rl0: RealTek 8139 10/100BaseTX port 0xbc00-0xbcff mem 0xefeeff00-0xefee irq 12 at device 9.0 on pci2 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:20:ed:40:16:0c miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative CT5880-E port 0xb800-0xb83f irq 11 at device 10.0 on pci2 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 ATA100 controller port 0xff00-0xff0f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus,
Re: Posix Semaphores in -CURRENT
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 look like this code allows a 14-character named
semaphore which *must* start with a slash and cannot contain embedded
slashes. In other words, it does *not* conform to pathname semantics.
OK, this is a bug. The semantics don't conform to POSIX.
It looks like FreeBSD's version doesn't use filesystem objects, and
makes up its own namespace (a flat one) in which to create the
semaphores. Even if it's not an FS thing, the POSIX semantics
pretty much guarantee at *least* the ability to create your own
named namespace, one deep, with the '/' as a namespace component
seperator, even if it's not a path component seperator.
I rather imagine the correct thing to do is to root it in the FS,
and, without a leading '/', treat it as relative to the process
current directory.
Basically, this is not a two line fix... it's a lot of work, to
get a filesystem object to use.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 04:10:39 GMT 2002 -- === ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 to handle the fact that the newly installed device /dev/random sucked too much CPU time to work on a 386. The /dev/random code has since improved to not suck so much CPU time, but the 386 code was not reenabled. The best answer out there is the majority has spoken, with the idea being that if you are deploying on 386 hardware, you are an embedded systems vendor, and are willing to live with the process effectively being a cross-compilation. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 have other issues in making sysinstall work and have to do custom hacking... Add to this that Bosko's workaround for the CPU bug with PSE/PGE includes loading the kernel at 4M rather than 1M. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
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 wanted FreeBSD on, I'd crack open the old FreeBSD 3.5 install CD's, assuming it even had a cdrom drive. I understand why people care about supporting older hardware. Reasons such as cost, and the ability to allow code bloat to _really_ manifest itself come to mind. However, a 386 is just too old for words and should be running older software with less features. -Craig - Original Message - From: Terry Lambert [EMAIL PROTECTED] To: M. Warner Losh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 14, 2002 23:55 Subject: Re: 80386 out of GENERIC 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 have other issues in making sysinstall work and have to do custom hacking... Add to this that Bosko's workaround for the CPU bug with PSE/PGE includes loading the kernel at 4M rather than 1M. -- Terry 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: cbb attach failed
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 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 (decoding 0xc020-0xcfff, 0xe800-0xf00f) cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 cbb0: RF5C476 PCI-CardBus Bridge mem 0x5010-0x50100fff irq 11 at device 3.1 on pci2 pcib2: device cbb0 requested unsupported memory range 0x0-0x0 (decoding 0xc020-0xcfff, 0xe800-0xf00f) cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 any suggestion? regards, 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
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Dec 14 22:07:13 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/ia64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sshd: fatal: ssh_msg_send: write
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. http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8threadm=aojom0%2414v4%241%40FreeBSD.csie.NCTU.edu.twrnum=2prev=/groups%3Fq%3Dssh_msg_send:%2Bwrite%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Daojom0%252414v4%25241%2540FreeBSD.csie.NCTU.edu.tw%26rnum%3D2 Is the suggested fix also valid for FreeBSD (its looks like an OpenBSD person) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
