Re: should new-gcc kernels with -CURRENT still be panic()'ing rightat boot?
[ On Tuesday, July 22, Steve Kargl wrote: ] > > I've built several kernels without a problem. You need > to (1) post the exact panic message, (2) read the section of > the Handbook on debugging kernel panics, and (3) provide a > backtrace. > Well, I went through the process anyway, just to learn how to do it. But, it was My Bad in 4.x on "older" hardware, I never had apm or apci compiled in. With 5.1-RELEASE and this new machine /boot/kernel/acpi.ko is always loaded during boot. Part of my regiment for testing new kernels was always to copy the kernel file to /boot and manually unload/load this new kernel and do a "boot -s" to make sure things were cool. I did that this time too, but the acpi.ko was the OLD one and that's what immediately panic'ed the system. I've since manually tested the kernel and its parts and also done an installkernel operation and things are cool--and my ICH5 AC'97 sound is now supported ;-) Thanks for the hints. -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.reynoldsnet.org Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! "Unix is user friendly, it's just particular about the friends it chooses." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is kern.ca.da.no_6_byte?
On Wed, Jul 23, 2003 at 12:00:00AM -0700, Terry Lambert wrote: > Josef Karthauser wrote: > > On Tue, Jul 22, 2003 at 11:31:21PM -0700, Terry Lambert wrote: > > > As far as I'm concerned, USB is a Very Black Art(tm), and has > > > been since day one. 8-(. You have to wonder how Windows > > > manages... > > > > Windows manages because it is in the vendor's interest for it to work > > and as such their install .inf script does the right thing, for some > > value of DTRT. > > This is the conspiracy theorist answer. I'm not saying that it > is wrong, but it seems to me that more stuff is "Plug-and-play" > without third party drivers in Windows, and without quirking. > That's true although there hardly seems a usb device that doesn't ask for an install disk! > If you want to push it out a bit, most USB stuff I've seen also > works with Macintosh systems, and *definitely* can't do anything > with a vendor supplied driver CDROM, so It Just Works(tm). Maybe > there is something to learn from Darwin in this area... I don't > know how public the USB code is at this point there, or if it is > published at all (though I thought it was). That's a fair point. I don't know the answer to this either. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
On Mon, 21 Jul 2003, David O'Brien wrote: DO>On Tue, Jul 15, 2003 at 07:59:43AM +0200, Harti Brandt wrote: DO>> On Tue, 15 Jul 2003, Jun Kuriyama wrote: DO>> JK>With new gcc and -Wshadow, src/bin/ed/re.c shows this warning: DO>> JK> DO>> JK>cc -Wshadow -c re.c DO>> JK>re.c: In function `get_compiled_pattern': DO>> JK>re.c:44: warning: declaration of `exp' shadows a global declaration DO>> JK>:0: warning: shadowed declaration is here DO>> JK> DO>> JK>It seems local variable exp is conflicted with exp(3) declaration. I DO>> JK>don't know what name should be used... DO>> DO>> I would call this a compiler bug. It shouldn't declare exp(3) when you DO>> don't include math.h. As I understand the standard the names in math.h are DO>> only reserved when you include math.h. I remember that an earlier version DO>> of gcc had this bug, that was fixed then. Probably they unfixed it again. DO>> DO>> What's the chance of getting this fixed? DO> DO>There is a discussion on the [EMAIL PROTECTED] mailing list, but DO>they are having a hard time agreeing there is a bug here. FreeBSD's GCC DO>problems have a better chance of getting fixed if those that experience DO>and understand the bug would participate in related discussions on the DO>GCC mailing lists. The Linux and Solaris community has no problem doing DO>this -- for some reason the BSD communities expects the poor guy doing DO>the GCC imports to be the single voice for BSD. :-( Well, I have subscribed. I red the messages in this thread and it seems, that there is more agreement that this needs to be fixed than people against it. I'm not familiar with the process in the gcc-community. Is there any action required? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-07-23 08:17:02 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-07-23 08:17:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-23 08:19:30 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> 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/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/syslog.3 > syslog.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/tcgetpgrp.3 > tcgetpgrp.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/tcsendbreak.3 > tcsendbreak.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/tcsetattr.3 > tcsetattr.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/tcsetpgrp.3 > tcsetpgrp.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/time.3 > time.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libc/gen/times.3 > times.3.gz Bus error (core dumped) *** Error code 138 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-07-23 08:59:15 - /usr/bin/make returned exit code 1 TB --- 2003-07-23 08:59:15 - ERROR: failed to build world TB --- 2003-07-23 08:59:15 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Buildworld Faild on 5.1-Release
Hi There, I have installed FreeBSD 5.1-Release and try to update to 5-CURRENT. Here is the errormessage i`ve get. mkdep -f .depend -a-I/usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libhdb/../../include -I/usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb -I/usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libhdb -I/usr/obj/usr/src/kerberos5/lib/libhdb/../../lib/libasn1 -I/usr/local/include -DOPENLDAP=1 -I/usr/src/kerberos5/lib/libhdb/../../include -DHAVE_CONFIG_H -DINET6 /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/common.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/db.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/db3.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/hdb-ldap.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/hdb.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/keytab.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/mkey.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/ndbm.c /usr/src/kerberos5/lib/libhdb/../../../crypto/heimdal/lib/hdb/print.c hdb_err.c asn1_Key.c asn1_GENERATION.c asn1_Event.c asn1_HDBFlags.c asn1_hdb_entry.c asn1_Salt.c /usr/src/crypto/heimdal/lib/hdb/hdb-ldap.c:39:18: lber.h: No such file or directory /usr/src/crypto/heimdal/lib/hdb/hdb-ldap.c:40:18: ldap.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/kerberos5/lib/libhdb. *** Error code 1 Stop in /usr/src/kerberos5/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 I have done the cvsup today 10:30 CEST. Bye Estartu Gerhard Schmidt| Nick : estartu IRC : Estartu | PGP Public Key Fischbachweg 3 | Privat: [EMAIL PROTECTED] | auf Anfrage/ 86856 Hiltenfingen | Dienst: [EMAIL PROTECTED] |on request pgp0.pgp Description: PGP signature
maildir with softupdates
Hello, Is this statement still valid? "ext3 is unsafe for maildir, and with softupdates, so is ffs." http://www.irbs.net/internet/postfix/0202/0358.html Thanks, -- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU) phone @work: +361 210 1415/127 ISOs: http://www.fsn.hu/?f=downloadcell.: +3630 306 6758 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release broken [FIX]
Hi
Please do not commit this.
M
Ruslan Ermilov writes:
>
> --A9z/3b/E4MkkD+7G
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Jul 22, 2003 at 07:42:33PM +0300, Ruslan Ermilov wrote:
> > Hi!
> >=20
> > As many of you probably know, recent telnet commit broke snapshot
> > building. Since I needed a working "make release" to go on with
> > my task on floppy-less "make release" (for AMD64, etc.), I had to
> > just fix it. Attached is the patch. It also fixes another issue
> > with this telnet commit: it ensures that crypto telnet[d] do not
> > end up in the "base" distribution.
> >=20
> Missed in the patch: set DISTRIBUTION=3Dcrypto in lib/libtelnet/Makefile,
> so that we still have crypto/usr/include/arpa/telnet.h.
>
> %%%
> Index: Makefile
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
> retrieving revision 1.16
diff -u -r1.16 Makefile
> --- Makefile 20 Jul 2003 23:29:46 - 1.16
> +++ Makefile 23 Jul 2003 06:37:09 -
> @@ -13,10 +13,11 @@
> =20
> WARNS?=3D2
> =20
> -.if !defined(NOCRYPT) && !defined(NO_OPENSSL)
> +.if exists(${.CURDIR}/../../crypto) && !defined(NOCRYPT) && !defined(NO_OP=
> ENSSL)
> +DISTRIBUTION=3D crypto
> SRCS+=3D encrypt.c auth.c enc_des.c sra.c pk.c
> CFLAGS+=3D -DENCRYPTION -DAUTHENTICATION -DSRA
> -.if !defined(NO_KERBEROS)
> +.if exists(${.CURDIR}/../../kerberos5) && !defined(NO_KERBEROS)
> SRCS+=3D kerberos5.c
> CFLAGS+=3D -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
> CFLAGS+=3D -DFORWARD -Dnet_write=3Dtelnet_net_write
> %%%
>
>
> Cheers,
> --=20
> Ruslan ErmilovSysadmin and DBA,
> [EMAIL PROTECTED] Sunbay Software Ltd,
> [EMAIL PROTECTED] FreeBSD committer
>
> --A9z/3b/E4MkkD+7G
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.1 (FreeBSD)
>
> iD8DBQE/Hi8lUkv4P6juNwoRArAKAJ0QpXpQ9YPuG5gXUo/5p+uia83CiACfTkYW
> Myhb+SttdXFnNahueIHJ7Us=
> =LyZK
> -END PGP SIGNATURE-
>
> --A9z/3b/E4MkkD+7G--
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release broken [FIX]
On Wed, Jul 23, 2003 at 11:33:50AM +0100, Mark Murray wrote: > Hi > > Please do not commit this. > Please stop repeating this endlessly. This patch is only for those who need a working "make release" urgently, like me. You made it clear that you're working on a better fix. -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Buildworld Faild on 5.1-Release
On Wed, 23 Jul 2003, Gerhard Schmidt wrote: > Hi There, > > I have installed FreeBSD 5.1-Release and try to update to 5-CURRENT. > > Here is the errormessage i`ve get. > ... You get this because you have in your /etc/make.conf: ... WITH_OPENLDAP=yes ... but have not installed the openldap port. Bye/2 --- Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consuling Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How to provide useful debug info
Hi all, I have currently at least 4 scenarios when my 5.1-release crashes on different hardware. So I built a kernel (GENERIC) with debugging symbols and DDB option. Now I'd like to provide usefull info about the following crashes: 1. booting from degraded RAID1 with HPT372 (machine crashes and I see db>) 2. crash when unquirked UMASS is unpluged 3. crash when /stand/sysinstall is called after some uptime 4. machine hangs when LPT is removed in BIOS and ACPI enabled (no crash, I think I have to enter DDB with ctrl-alt-esc?) I read the FAQ (18.13. How can I make the most of the data I see when my kernel panics?) but I think this isn't applicable to my crash when the machine crashes before rc.conf can be read. And I really don't understand what he's talking about :( but perhaps I can help. Please tell me if I should do something like "trace" and write it down or something like that. Thanks, -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing gcc 3.3 compile failures -- fix for audio/xmixer
--- Xw/Base.c.orig Wed Jul 23 03:56:03 2003 +++ Xw/Base.c Wed Jul 23 03:56:43 2003 @@ -89,8 +89,8 @@ * default translation table */ static char defaultTranslations [] = "\ -: focus(in) -: focus(out) +: focus(in)\n\ +: focus(out)\n\ Tab: tab()"; /* signature.asc Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for audio/xmms-tfmx
--- src/xmms_about.c.orig Wed Jul 23 04:53:36 2003 +++ src/xmms_about.cWed Jul 23 04:54:43 2003 @@ -20,11 +20,11 @@ gtk_container_border_width(GTK_CONTAINER(hbox1), 5); label = gtk_label_new( - " -TFMX plugin adapted to xmms by David Le Corfec -<[EMAIL PROTECTED]> -Original code (tfmxplay) by Jonathan H. Pickard, ported to Winamp by Per Linden\n -TFMX was created by Chris Huelsbeck. + "\ +TFMX plugin adapted to xmms by David Le Corfec\ +<[EMAIL PROTECTED]>\n\ +Original code (tfmxplay) by Jonathan H. Pickard, ported to Winamp by Per Linden\n\ +TFMX was created by Chris Huelsbeck.\ "); gtk_box_pack_start(GTK_BOX(dialog_vbox1), label, TRUE, TRUE, 5); signature.asc Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for games/xjumpjump
--- texts.h.origWed Jul 23 03:48:19 2003 +++ texts.h Wed Jul 23 03:48:56 2003 @@ -1,6 +1,6 @@ #define E_MY_PRGNAME "xjumpjump" -#define E_VERSION"JumpJump-0.12 for X, Feb 26th 1997 by +#define E_VERSION"JumpJump-0.12 for X, Feb 26th 1997 by \ nihil ([EMAIL PROTECTED])" #define E_MY_TITLE "XJumpJump v0.12" #define E_MY_TITLE2 "by nihil\nHungary\n1997.02.26" @@ -9,7 +9,7 @@ #define E_STR_PRACTISE "Hmm... practise a bit more!" #define H_STR_PRACTISE "Hmm... gyakorolj még egy picit!" #define E_STR_CONGRAT"Congratulations! You have succeed!" -#define H_STR_CONGRAT"Gratulálok! Sikerült ezt a pályát +#define H_STR_CONGRAT"Gratulálok! Sikerült ezt a pályát \ leküzdened!" #define E_STR_BUT_NEW"New Game" signature.asc Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for graphics/xmms-gforce
--- _Unix-X/libxpce/xvhandler.c.origWed Jul 23 04:43:19 2003
+++ _Unix-X/libxpce/xvhandler.c Wed Jul 23 04:44:31 2003
@@ -342,7 +342,7 @@
/* x_DCTCEDoComp() - Do one component for DCTCE */
int x_DCTCEDoComp(int mask, int color) {
- static const char cnames[] = { "red", "green", "blue" };
+ static const char cnames[3][20] = { "red", "green", "blue" };
static const char cflags[] = { DoRed, DoGreen, DoBlue };
static unsigned long int * const carrays[] = { X_redmap,
X_greenmap,
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for math/surf
--- Makefile.orig Tue Jul 22 17:13:04 2003
+++ MakefileTue Jul 22 17:13:15 2003
@@ -7,7 +7,7 @@
#
PORTNAME= surf
-PORTVERSION= 1.0.3
+PORTVERSION= 1.0.4
CATEGORIES=math
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=${PORTNAME}
@@ -27,9 +27,5 @@
MAN1= surf.1
.include
-
-.if ${OSVERSION} >= 500113
-BROKEN= "Does not compile (bad C++ code)"
-.endif
.include
--- distinfo.orig Mon Apr 23 18:52:21 2001
+++ distinfoTue Jul 22 16:03:51 2003
@@ -1 +1 @@
-MD5 (surf-1.0.3.tar.gz) = 4d0cea15d9e771e60920dbb25979d1f3
+MD5 (surf-1.0.4.tar.gz) = 4880ecf3d4207ab0a4f2a2f017383b65
--- gtkgui/MainWindowController.cc.orig Tue Jul 22 16:23:20 2003
+++ gtkgui/MainWindowController.cc Tue Jul 22 16:23:30 2003
@@ -28,7 +28,7 @@
#include
-#include
+#include
// #define DEBUG
#include "debug.h"
--- gtkgui/Requester.cc.origTue Jul 22 16:23:45 2003
+++ gtkgui/Requester.cc Tue Jul 22 16:24:01 2003
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
#include
--- gtkgui/SaveImageDialog.cc.orig Tue Jul 22 16:24:13 2003
+++ gtkgui/SaveImageDialog.cc Tue Jul 22 16:26:31 2003
@@ -23,9 +23,11 @@
*/
-#include
+#include
#include "SaveImageDialog.h"
+
+using std::ostrstream;
void SaveImageDialog::toggled_dither_method (GtkWidget *w, gpointer data)
{
--- gtkgui/mycolor.cc.orig Tue Jul 22 16:22:12 2003
+++ gtkgui/mycolor.cc Tue Jul 22 16:22:26 2003
@@ -26,7 +26,7 @@
#include
#include
#include
-#include
+#include
#include
#include
--- misc/Misc.h.origTue Jul 22 16:14:35 2003
+++ misc/Misc.h Tue Jul 22 16:14:59 2003
@@ -26,7 +26,9 @@
#ifndef MISC_H
#define MISC_H
-#include
+#include
+
+using std::ostrstream;
class Misc
{
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for math/topaz
--- Makefile.orig Wed Jul 23 15:02:46 2003
+++ MakefileWed Jul 23 15:03:08 2003
@@ -6,7 +6,7 @@
#
PORTNAME= topaz
-PORTVERSION= 3.38
+PORTVERSION= 3.39
CATEGORIES=math
MASTER_SITES= http://hp.vector.co.jp/authors/VA007663/topaz/bin/
DISTNAME= ${PORTNAME}-${PORTVERSION:S/./_/}-src
--- distinfo.orig Wed Jul 23 15:02:50 2003
+++ distinfoWed Jul 23 15:02:55 2003
@@ -1 +1 @@
-MD5 (topaz-3_38-src.tar.gz) = b91080b08c836890232b715088d2c34f
+MD5 (topaz-3_39-src.tar.gz) = 5c6179aeb87a4809b9c78d8f1b5e3755
--- topaz/tpv2ps.cc.origFri Jun 27 14:35:40 2003
+++ topaz/tpv2ps.cc Wed Jul 23 15:12:54 2003
@@ -31,7 +31,7 @@
#include
#include
#include
-#include
+//#include
//char *optarg;
extern int errno;
@@ -63,7 +63,7 @@
#define buffersize 1024
-char* entry[] = {
+const char entry[13][40] = {
{"Times-Roman-Q"},
{"Times-Bold-Q"},
{"Times-Italic-Q"},
@@ -79,7 +79,7 @@
{"Symbol"}
};
-char* kentry[] = {
+const char kentry[8][30] = {
{"Ryumin-Light-H"},
{"Ryumin-Light-H"},
{"Ryumin-Light-H"},
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for net/tp5250
--- src/tn5250.c.orig Tue Jul 22 18:25:06 2003
+++ src/tn5250.cTue Jul 22 18:25:31 2003
@@ -179,7 +179,7 @@
tn5250 [options] HOST[:PORT]\n");
#ifdef HAVE_LIBSSL
printf("\
- To connect using ssl prefix HOST with 'ssl:'. Example:
+ To connect using ssl prefix HOST with 'ssl:'. Example:\n\
tn5250 +ssl_verify_server ssl:as400.example.com\n");
#endif
printf ("\n\
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for print/unrtf
--- ps.c.orig Tue Jul 22 18:56:13 2003
+++ ps.cTue Jul 22 19:02:44 2003
@@ -187,7 +187,7 @@
/didShowPage false def \n\
%%--\n\
%% Set up the ISO fonts \n\
-
+\n\
%% Times \n\
%% - \n\
/Times-Roman findfont dup length dict begin { \n\
@@ -196,28 +196,28 @@
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/TRomanISO exch definefont pop \n\
-
+\n\
/Times-Bold findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/TBoldISO exch definefont pop \n\
-
+\n\
/Times-BoldItalic findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/TBoldItalicISO exch definefont pop\n\
-
+\n\
/Times-Italic findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/TItalicISO exch definefont pop\n\
-
+\n\
%% Courier \n\
%% - \n\
/Courier-Roman findfont dup length dict begin {\n\
@@ -226,28 +226,28 @@
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/CRomanISO exch definefont pop \n\
-
+\n\
/Courier-Bold findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/CBoldISO exch definefont pop \n\
-
+\n\
/Courier-BoldItalic findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/CBoldItalicISO exch definefont pop\n\
-
+\n\
/Courier-Italic findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/CItalicISO exch definefont pop\n\
-
+\n\
%% Symbol \n\
%% - \n\
/Symbol-Roman findfont dup length dict begin { \n\
@@ -256,28 +256,28 @@
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/SRomanISO exch definefont pop \n\
-
+\n\
/Symbol-Bold findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/SBoldISO exch definefont pop \n\
-
+\n\
/Symbol-BoldItalic findfont dup length dict begin {\n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/SBoldItalicISO exch definefont pop\n\
-
+\n\
/Symbol-Italic findfont dup length dict begin {\n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/SItalicISO exch definefont pop\n\
-
+\n\
%% Helvetica \n\
%% - \n\
/Helvetica-Roman findfont dup length dict begin { \n\
@@ -286,28 +286,28 @@
/Encoding ISOLatin1Encoding def\n\
currentdict end\n\
/HRomanISO exch definefont pop \n\
-
+\n\
/Helvetica-Bold findfont dup length dict begin { \n\
1 index /FID ne { def } { pop pop } ifelse \n\
} forall \n\
/
Re: Fixing gcc 3.3 compile failures -- fix for textproc/xmlpp
--- Makefile.orig Wed Jul 23 04:08:36 2003
+++ MakefileWed Jul 23 04:09:11 2003
@@ -21,12 +21,9 @@
.include
-.if ${OSVERSION} >= 500113
-BROKEN= "Does not compile (bad C++ code)"
-.endif
-
pre-patch:
@${FIND} ${WRKSRC} -name "Makefile.in" | ${XARGS} ${REINPLACE_CMD} -e \
's|/usr/local/share|$$(datadir)|g'
+ @${RM} ${WRKSRC}/config.cache
.include
--- src/xmlcommon.h.origWed Jul 23 04:10:04 2003
+++ src/xmlcommon.h Wed Jul 23 04:12:03 2003
@@ -20,6 +20,8 @@
//! dummy define
#define XMLPP_API
+
+using std::string;
//! handle to a tagname string in a tagname map
typedef int xmltagnamehandle;
--- ./src/xmlpp.cpp.origWed Jul 23 04:12:52 2003
+++ ./src/xmlpp.cpp Wed Jul 23 04:13:52 2003
@@ -21,6 +21,12 @@
//debug
#include
+using std::cout;
+using std::cerr;
+using std::endl;
+using std::ifstream;
+using std::ofstream;
+
namespace xmlpp {
// internal use for saving
--- src/xmltokenizer.cpp.orig Wed Jul 23 04:14:53 2003
+++ src/xmltokenizer.cppWed Jul 23 04:29:18 2003
@@ -15,7 +15,7 @@
// needed includes
#include "xmlpp.h"
#include "xmltokenizer.h"
-
+#include
// namespace declaration
namespace xmlpp {
--- test/nodetest.cpp.orig Wed Jul 23 04:18:02 2003
+++ test/nodetest.cpp Wed Jul 23 04:19:01 2003
@@ -5,6 +5,7 @@
*/
#include
+#include
#include "xmlpp.h"
using namespace xmlpp;
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -fix for textproc/xmlppm
--- IFile.cpp.orig Wed Jul 23 04:32:54 2003
+++ IFile.cpp Wed Jul 23 04:35:43 2003
@@ -100,7 +100,7 @@
while(insz > 0) {
size_t result;
outsz = BUFFSIZE;
-result = iconv(ifile->iconv, &(char*)inptr, &insz, &outptr, &outsz);
+result = iconv(ifile->iconv, &inptr, &insz, &outptr, &outsz);
total += fwrite(outbuf, sizeof(char), BUFFSIZE-outsz, ifile->file);
if(result == (size_t)-1 && errno != E2BIG) {
return total;
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for x11-toolkits/wmapp
--- wmapp.cc.orig Wed Jul 23 03:26:58 2003
+++ wmapp.ccWed Jul 23 03:28:59 2003
@@ -4,11 +4,9 @@
using std::string;
-namespace Unix {
- extern "C" {
-# include // for usleep()
- }
-};
+extern "C" {
+# include // for usleep()
+}
// All the xpms we need:
namespace Xpms {
@@ -254,7 +252,7 @@
while (true) {
// sleep for the specified time in milliseconds
-Unix::usleep(1000 * current()->updatefreq());
+usleep(1000 * current()->updatefreq());
// execute any timed functions which need it
current()->run_timed_functions();
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for x11toolkits/viewklass
These are quite a lot of files, so I put them into a tar archive http://www.leo.org/~barner/freebsd/x11-toolkits-viewklass_port_patch.tar.gz signature.asc Description: Digital signature
Re: How to provide useful debug info
Hi, Generally the minimum required information is /var/run/dmesg.boot and a stack backtrace at the crash. See http://www.uk.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html, particularly 17.4 and 17.5 At 13:13 23/7/03, Harald Schmalzbauer wrote: Hi all, I have currently at least 4 scenarios when my 5.1-release crashes on different hardware. So I built a kernel (GENERIC) with debugging symbols and DDB option. Now I'd like to provide usefull info about the following crashes: 1. booting from degraded RAID1 with HPT372 (machine crashes and I see db>) 2. crash when unquirked UMASS is unpluged 3. crash when /stand/sysinstall is called after some uptime 4. machine hangs when LPT is removed in BIOS and ACPI enabled (no crash, I think I have to enter DDB with ctrl-alt-esc?) I read the FAQ (18.13. How can I make the most of the data I see when my kernel panics?) but I think this isn't applicable to my crash when the machine crashes before rc.conf can be read. And I really don't understand what he's talking about :( but perhaps I can help. Please tell me if I should do something like "trace" and write it down or something like that. Thanks, -Harry -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compaq Evo N610c
Hi, It seems some things are getting some where... pcmcia cards work only (at least one) if you put more than one card in the pcmcia slots. So inserting a Lucent orinoco wireless fails but the second ASUS wireless card gets working ... And also the reverse can be done.. It's strange but it gives a working wireless connection. I have a dmesg verbose on my website: http://www.guldan.cistron.nl/dmesg_output2.txt the older version is: http://www.guldan.cistron.nl/dmesg_output.txt Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: Compaq Evo N610c
Hi, It seems some things are getting some where... pcmcia cards work only (at least one) if you put more than one card in the pcmcia slots. So inserting a Lucent orinoco wireless fails but the second ASUS wireless card gets working ... And also the reverse can be done.. It's strange but it gives a working wireless connection. I have a dmesg verbose on my website: http://www.guldan.cistron.nl/dmesg_output2.txt the older version is: http://www.guldan.cistron.nl/dmesg_output.txt Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
RE: How to provide useful debug info
Bob Bishop wrote: > Hi, > > Generally the minimum required information is /var/run/dmesg.boot and a > stack backtrace at the crash. > > See > http://www.uk.freebsd.org/doc/en_US.ISO8859-1/books/developers-han > dbook/kerneldebug.html, > particularly 17.4 and 17.5 Thank you for that link, but that's far too complicated for me. I don't know any of these gdb commands, I can just feed you with info. So as far as I understand, if I enter "trace" at any point when I see "db>" that's what you need is it? Thanks, -Harry > > At 13:13 23/7/03, Harald Schmalzbauer wrote: > >Hi all, > > > >I have currently at least 4 scenarios when my 5.1-release crashes on > >different hardware. > >So I built a kernel (GENERIC) with debugging symbols and DDB option. > >Now I'd like to provide usefull info about the following crashes: > > > >1. booting from degraded RAID1 with HPT372 (machine crashes and > I see db>) > > > >2. crash when unquirked UMASS is unpluged > > > >3. crash when /stand/sysinstall is called after some uptime > > > >4. machine hangs when LPT is removed in BIOS and ACPI enabled > (no crash, I > >think I have to enter DDB with ctrl-alt-esc?) > > > >I read the FAQ (18.13. How can I make the most of the data I see when my > >kernel panics?) but I think this isn't applicable to my crash when the > >machine crashes before rc.conf can be read. And I really don't understand > >what he's talking about :( but perhaps I can help. > > > >Please tell me if I should do something like "trace" and write it down or > >something like that. > > > >Thanks, > > > >-Harry > > > -- > Bob Bishop+44 (0)118 977 4017 > [EMAIL PROTECTED] fax +44 (0)118 989 4254 > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated cpuid = 2; lapic.id = 0100 boot() called on cpu#2 syncing disks, buffers remaining... 7149 7148 7148 7148 7143 7151 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 7143 kernel paniced again... this time with the re-compiled 5.1-R kernel with the 1.126 kern_malloc.c file. I was looking at uping the kern.vm.kmem.size as suggested to do as well, but I cannot find that value in sysctl -a, so I'm not sure where to set that specifically. I have found the value for nmbclusters and it is set to the following: kern.ipc.nmbclusters: 25600 I guess short of setting the kern.vm.kmem.size I need to get someone here the stack trace leading to the crash... is there a URL that someone can point me to for me to set the box up for this? I'll dig around in the developers handbook, I seem to remember seeing something about it in there. Thanks, Stephane. - Original Message - From: ""Stephane Raimbault"" <[EMAIL PROTECTED]> Newsgroups: mailing.freebsd.current Sent: Tuesday, July 22, 2003 0:33 Subject: Re: FreeBSD 5.1-R kernel panic > Hi Thanks for your response, > > I do not have PAE enabled... I've been hesitant of turning it on, I'm not > sure if it's too stable, I noticed that the asr driver is in the nodriver > list in the PAE kernel config file and I use the asr driver for my Adaptec > 2015S raid card. If you think its safe to enable PAE with my current setup, > please let me know, I do have 2 more gig's of ram in this particular box > that I'd like to enable if it doesn't compromise system stability. > > I will re-compile the kernel with the kern_malloc.c as you suggested, > however I see that 1.126 fixes a PAE issue, so I'm not sure if that's going > to help me out much. > > Where can I get information on how to get my kernel to provide a stack > trace? I have done little of this type of troubleshooting, but would like > to provide as much info before I'm forced to revert to 4.8-R in hopes to > return stability to our system. If the new kernel with the updated > kern_malloc.c doesn't help, I'll look at increasing the values you > suggested. > > Thanks for the info, and I'll keep you posted with what I find. > > Thanks again, > Stephane Raimbault > > - Original Message - > From: "Bosko Milekic" <[EMAIL PROTECTED]> > Newsgroups: mailing.freebsd.current > Sent: Monday, July 21, 2003 16:36 > Subject: Re: FreeBSD 5.1-R kernel panic > > > > > > On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote: > > > I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the > > > following kernel panic. > > > > > > panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated > > > > > > I'm trying to figure out what could be causing this, what kind of > > > information that I could provide to this group (or other group?) to see > if > > > this is a bug in FreeBSD that needs to be looked into? > > > > > > The box is basically a busy apache server... the kernel panic seemed to > > > occur during the periodic daily was running. It seems to complete the > > > 440.status-mailq part of periodic daily , but doesn't do > > > 450.status-security. > > > > > > This isn't the first time the box has crashed at aprox. 3:01 am (when > daily > > > runs)... however this is the first time I've seend the kernel panic > message > > > quoted above in the /var/run/dmesg.boot file. > > > > > > I have attached the entire /var/run/dmesg.boot file to this message. > > > > > > What can I do to assist in identifiying and resolving this problem? > > > > > > Thanks, > > > Stephane Raimbault. > > > > Just a few things: > > > > 1) Do you have PAE enabled? > > > > 2) Can you upgrade to src/sys/kern/kern_malloc.c version 1.126 or > > upgrade to HEAD? > > > > If you have PAE enabled and (2) does not fix your problem, then please > > post a stack trace that resulted in the panic. You also have a lot of > > RAM so if (2) above does not fix your problem, try setting the > > kern.vm.kmem.size bootable to approximately 350,000,000 or so (even > > 400,000,000 is OK as long as NMBCLUSTERS is not too-too high). > > > > -- > > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] > > TECHNOkRATIS Consulting Services * http://www.technokratis.com/ > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Wed, Jul 23, 2003 at 09:08:18AM -0600, Stephane Raimbault wrote: ... > I was looking at uping the kern.vm.kmem.size as suggested to do as well, but > I cannot find that value in sysctl -a, so I'm not sure where to set that > specifically. I have found the value for nmbclusters and it is set to the > following: It's a boot-time tunable. Look at /boot/defaults/loader.conf and copy over the relevant line with a setting such as, for example, 35 into your /boot/loader.conf. Increasing nmbclusters will not help you here. In fact, if you're not running out, I would recommend keeping the value reasonable (e.g., 8192). > kern.ipc.nmbclusters: 25600 > > I guess short of setting the kern.vm.kmem.size I need to get someone here > the stack trace leading to the crash... is there a URL that someone can > point me to for me to set the box up for this? I'll dig around in the > developers handbook, I seem to remember seeing something about it in there. > > Thanks, > Stephane. ... -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compaq Evo N610c
On Wed, Jul 23, 2003 at 03:45:48PM +0200, Robert Blacquière wrote: > > pcmcia cards work only (at least one) if you put more than one card in > the pcmcia slots. > So inserting a Lucent orinoco wireless fails but the second ASUS > wireless card gets working ... > And also the reverse can be done.. > It's strange but it gives a working wireless connection. I'd look for port address conflicts. On my Dell I5000, the ltmdm uses ports that the card drivers don't seem to notice (or vice versa). The result is that I have to wait to load if_dc until after the ltmdm is loaded. One way to see if this is happening to you is to boot without the card and see if it then works when you plug it in. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
Thanks Bosko, I've changed my /boot/loader.conf to reflect the kern.vm.kmem.size option. kern.vm.kmem.size="35" As far as changing the nmbclusters, I'm not sure how many I use now. Do you know where I could get some values as what the total vs. how much is being used for the above values? I'll setup some graphs to monitor those values for me and get an idea of how much the system is using and when if I can. Also, I took a quick look at the developers handbook and couldn't find just yet what I needed to change to the kernel to provide a stack trace... do you know what options I should be adding to my kernel? Also, should I try not to use an SMP kernel and just run GENERIC to see if continues to have the problem? I can probably run on one CPU for a few days, especially over the weekend. Thanks, Stephane. - Original Message - From: "Bosko Milekic" <[EMAIL PROTECTED]> Newsgroups: mailing.freebsd.current Sent: Wednesday, July 23, 2003 9:14 Subject: Re: FreeBSD 5.1-R kernel panic > > On Wed, Jul 23, 2003 at 09:08:18AM -0600, Stephane Raimbault wrote: > ... > > I was looking at uping the kern.vm.kmem.size as suggested to do as well, but > > I cannot find that value in sysctl -a, so I'm not sure where to set that > > specifically. I have found the value for nmbclusters and it is set to the > > following: > > It's a boot-time tunable. Look at /boot/defaults/loader.conf and copy > over the relevant line with a setting such as, for example, 35 > into your /boot/loader.conf. Increasing nmbclusters will not help you > here. In fact, if you're not running out, I would recommend keeping > the value reasonable (e.g., 8192). > > > kern.ipc.nmbclusters: 25600 > > > > I guess short of setting the kern.vm.kmem.size I need to get someone here > > the stack trace leading to the crash... is there a URL that someone can > > point me to for me to set the box up for this? I'll dig around in the > > developers handbook, I seem to remember seeing something about it in there. > > > > Thanks, > > Stephane. > ... > > -- > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] > TECHNOkRATIS Consulting Services * http://www.technokratis.com/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
On Wed, Jul 23, 2003 at 09:24:24AM -0600, Stephane Raimbault wrote: > Thanks Bosko, > > I've changed my /boot/loader.conf to reflect the kern.vm.kmem.size option. > > kern.vm.kmem.size="35" > > As far as changing the nmbclusters, I'm not sure how many I use now. Do you > know where I could get some values as what the total vs. how much is being > used for the above values? I'll setup some graphs to monitor those values > for me and get an idea of how much the system is using and when if I can. 'netstat -m' You can access the relevant sysctls directly; take a look at the way netstat does it in src/usr.bin/netstat/mbuf.c > Also, I took a quick look at the developers handbook and couldn't find just > yet what I needed to change to the kernel to provide a stack trace... do you > know what options I should be adding to my kernel? Also, should I try not > to use an SMP kernel and just run GENERIC to see if continues to have the > problem? I can probably run on one CPU for a few days, especially over the > weekend. At the very least, you need "options DDB". This will drop you into the debugger on a kernel panic, at which point you can just issue 'tr' to get a stack trace. Be careful, if you only have remote access to the machine, this is generally not a good idea. > Thanks, > Stephane. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: maildir with softupdates
Attila Nagy wrote: Hello, Is this statement still valid? "ext3 is unsafe for maildir, and with softupdates, so is ffs." http://www.irbs.net/internet/postfix/0202/0358.html Yes, It's also true that any form of write-caching is unsafe, so disable the caches on your SCSI and ATA hard drives. Simply accept the terrible performance hit if you want super-reliability. Also, make sure you have redundant power supplies, UPSes and a diesel generator out back to cover power problems. In reality, anything comes with a certain amount of risk, and that statement is too vague to be useful. To my knowledge, ext3 is not unsafe by nature, it is simply unsafe by default because the default mount is async - which will generally be corrupted in the event of hardware failure. UFS+softupdates generally survives hardware failure without corruption, although it has a funny habit of losing files that were saved right before the failure. Result being that you could lose emails. However ... even a sync mount can become corrupt in the event of hardware failure, although it's much less likely. So you need to determine the risk level you're willing to accept as well as the performance you require. And you probably need to do more research than accepting that one-line statement, as it's too vague to properly describe the potential risk/benefits. This reminds me of the days when DOS first got disk-caching via a TSR (what was the name of that thing) and all the IT folks kept saying "Don't use it, it's dangerous" without understanding why it was dangerous. I used it anyway, because it improved performance considerably. Also, this is off-topic for -CURRENT, please remove -CURRENT from the CCs if you respond. I'm redirecting to -QUESTIONS for future discussion. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
Hi Bosko, Looking at netstat -m, the value I'd probably be interested in is the following: 3% of cluster map consumed knowing that the Maximum possible is 25600 I can deduce that ~768 are being used? Is that correct. I'm not much of a programmer, but I did recognize the printf(); statements from a C class I didn't do well in half a decade ago... as you can tell, I'm not much of a programmer :). If it's not the 3% I should be paying attention too... then let me know :) As for using the option DDB in my kernel, I do have one question. I do have remote console access that I use to go into single user mode on the box remotely. I'm suspecting I could use the debugger mode over the comconsole... I just want to make sure there is some kind of reboot command from the debugger so that I can tell the box to reboot once I've captured the stack trace? If so, I'll enable the DDB tonight and get you the info as soon as I can. thanks again, Stephane. - Original Message - From: "Bosko Milekic" <[EMAIL PROTECTED]> Newsgroups: mailing.freebsd.current Sent: Wednesday, July 23, 2003 9:28 Subject: Re: FreeBSD 5.1-R kernel panic > > On Wed, Jul 23, 2003 at 09:24:24AM -0600, Stephane Raimbault wrote: > > Thanks Bosko, > > > > I've changed my /boot/loader.conf to reflect the kern.vm.kmem.size option. > > > > kern.vm.kmem.size="35" > > > > As far as changing the nmbclusters, I'm not sure how many I use now. Do you > > know where I could get some values as what the total vs. how much is being > > used for the above values? I'll setup some graphs to monitor those values > > for me and get an idea of how much the system is using and when if I can. > > 'netstat -m' > > You can access the relevant sysctls directly; take a look at the way > netstat does it in src/usr.bin/netstat/mbuf.c > > > Also, I took a quick look at the developers handbook and couldn't find just > > yet what I needed to change to the kernel to provide a stack trace... do you > > know what options I should be adding to my kernel? Also, should I try not > > to use an SMP kernel and just run GENERIC to see if continues to have the > > problem? I can probably run on one CPU for a few days, especially over the > > weekend. > > At the very least, you need "options DDB". This will drop you into > the debugger on a kernel panic, at which point you can just issue 'tr' > to get a stack trace. Be careful, if you only have remote access to > the machine, this is generally not a good idea. > > > Thanks, > > Stephane. > > > -- > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] > TECHNOkRATIS Consulting Services * http://www.technokratis.com/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floppyless release build of sparc64
Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300,
Ruslan Ermilov said words to the effect of;
> A similar change would be in order for sparc64. Patch is
> attached, please review. The net effect is that we save
> huge CPU times in release.9 and do not create the useless
> boot.flp floppy image (the sparc64/mkisoimages.sh script
> doesn't need it).
boot.flp is actually useful on sparc64 because you can dd it to a disk
from solaris and then boot off it to install. I'm happy with having
the option of not building it if it saves time but please make it an
option.
Jake
>
> On Tue, Jul 22, 2003 at 10:53:53PM -0700, Ruslan Ermilov wrote:
> > ru 2003/07/22 22:53:53 PDT
> >
> > FreeBSD src repository
> >
> > Modified files:
> > release Makefile
> > Log:
> > Do not define BIGBOOTSIZE and the friends for amd64; it serves
> > no useful purpose other than wasting CPU time in "make release"
> > creating useless boot.flp.
> >
> > Desired by: peter
> >
> > Revision ChangesPath
> > 1.789 +0 -3 src/release/Makefile
>
>
> Cheers,
> --
> Ruslan ErmilovSysadmin and DBA,
> [EMAIL PROTECTED] Sunbay Software Ltd,
> [EMAIL PROTECTED] FreeBSD committer
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/release/Makefile,v
> retrieving revision 1.790
> diff -u -r1.790 Makefile
> --- Makefile 23 Jul 2003 06:00:56 - 1.790
> +++ Makefile 23 Jul 2003 06:09:41 -
> @@ -202,11 +202,8 @@
> BIGBOOTLABEL=minimum2
> .elif ${TARGET_ARCH} == "sparc64"
> DISKLABEL= sunlabel
> -BIGBOOTSIZE= 4096
> MFSSIZE= 4096
> -BOOTINODE= 8192
> MFSINODE=8192
> -BIGBOOTLABEL=auto
> MFSLABEL=auto
> .elif ${TARGET_ARCH} == "ia64"
> BIGBOOTLABEL=efi
> Index: sparc64/dokern.sh
> ===
> RCS file: sparc64/dokern.sh
> diff -N sparc64/dokern.sh
> --- sparc64/dokern.sh 13 Oct 2002 18:36:06 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,6 +0,0 @@
> -#!/bin/sh
> -#
> -# $FreeBSD: src/release/sparc64/dokern.sh,v 1.1 2002/10/13 18:36:06 jake Exp $
> -#
> -
> -sed -e 's/ident.*GENERIC/ident BOOTMFS/g'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floppyless release build of sparc64
On Wed, Jul 23, 2003 at 11:57:58AM -0400, Jake Burkholder wrote: > Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300, > Ruslan Ermilov said words to the effect of; > > > A similar change would be in order for sparc64. Patch is > > attached, please review. The net effect is that we save > > huge CPU times in release.9 and do not create the useless > > boot.flp floppy image (the sparc64/mkisoimages.sh script > > doesn't need it). > > boot.flp is actually useful on sparc64 because you can dd it to a disk > from solaris and then boot off it to install. I'm happy with having > the option of not building it if it saves time but please make it an > option. > OK, then things will be left as is. There's already an option for this; it's called NO_FLOPPIES (documented in the release(7) manpage). Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: FreeBSD 5.1-R kernel panic
On Wed, Jul 23, 2003 at 09:56:32AM -0600, Stephane Raimbault wrote: > Hi Bosko, > > Looking at netstat -m, the value I'd probably be interested in is the > following: > > 3% of cluster map consumed > > knowing that the Maximum possible is 25600 I can deduce that ~768 are being > used? Is that correct. I'm not much of a programmer, but I did recognize > the printf(); statements from a C class I didn't do well in half a decade > ago... as you can tell, I'm not much of a programmer :). If it's not the 3% > I should be paying attention too... then let me know :) Look at the "in pool" values for all the pcpu and GEN caches and add them up. Do this for clusters (since there are fewer). Compare to the "Maximum Possible" value. With a machine that goes into spike-load periods, you may want to have the Maximum Possible stay about 4-6 times what you have as your average "in pool" value (remember to sum the "in pool" values for the pcpu and GEN caches). The 3% is not what you think it is. It's the percentage of the allocated wired-down memory that is NOT in any of the caches but is allocated and circulating in the system. If you have a high number of cached items but the percentage is relatively low for most of the time, it's a sign that you were probably in a heavy-usage scenario some time ago, but that your current usage is relatively low. > As for using the option DDB in my kernel, I do have one question. I do have > remote console access that I use to go into single user mode on the box > remotely. I'm suspecting I could use the debugger mode over the > comconsole... I just want to make sure there is some kind of reboot command > from the debugger so that I can tell the box to reboot once I've captured > the stack trace? If so, I'll enable the DDB tonight and get you the info as > soon as I can. Yes, you can do DDB over serial console. Take a look at the handbook for more information on using DDB. If you have the space in /var and enough swap, you may want to try getting a crashdump so that you can reboot and use GDB to debug. Again, take a look at the handbook. > thanks again, > Stephane. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Portable USB hard drive regression
I have a Storix Fusion USB 60GB hard drive. It used to work on 5.0-CURRENT. I tried using it again after I noticed the "USB crapiness" thread, and it's now giving the following errors when I plug it into 5.1-CURRENT umass0: NewAge International STORIX Fusion25, rev 2.00/11.00, addr 3 umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-07-23 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-23 16:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-23 16:02:15 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> 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/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/close.2 > close.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/connect.2 > connect.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/dup.2 > dup.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/execve.2 > execve.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/extattr_get_file.2 > extattr_get_file.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/fcntl.2 > fcntl.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/fhopen.2 > fhopen.2.gz Bus error (core dumped) *** Error code 138 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-07-23 16:43:58 - /usr/bin/make returned exit code 1 TB --- 2003-07-23 16:43:58 - ERROR: failed to build world TB --- 2003-07-23 16:43:58 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible unionfs bug
On Sun, Jul 20, 2003, Divacky Roman wrote: > Hi, > > I might be wrong but this: > > free(mp->mnt_data, M_UNIONFSMNT); /* XXX */ > mp->mnt_data = 0; > > seems to me wrong and might cause crashes etc. > am I correct or wrong? > > its from union_vfsops.c:384 What's wrong with it? It's just freeing the memory it allocated earlier. FFS does the same thing. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: maildir with softupdates
On Wed, Jul 23, 2003, Attila Nagy wrote: > Hello, > > Is this statement still valid? > > "ext3 is unsafe for maildir, and with softupdates, so is ffs." > http://www.irbs.net/internet/postfix/0202/0358.html The statement is FUD; this is a topic that mailer people love to complain about. It's only true if your MTA doesn't call fsync() when it wants to guarantee that the file it just wrote is on stable storage. Most filesystems don't guaranteed 100% synchronous semantics for regular data unless you ask for them explicitly, due to the performance implications. The statement you quote used to be true for ext3 due to an inadequacy in its fsync() implementation, and I'm not sure if that was ever fixed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Portable USB hard drive regression
Mike Makonnen wrote this message on Wed, Jul 23, 2003 at 12:43 -0400: > I have a Storix Fusion USB 60GB hard drive. It used > to work on 5.0-CURRENT. I tried using it again after > I noticed the "USB crapiness" thread, and it's now > giving the following errors when I plug it into > 5.1-CURRENT > > umass0: NewAge International STORIX Fusion25, rev 2.00/11.00, addr 3 > umass0: BBB reset failed, TIMEOUT > umass0: BBB reset failed, TIMEOUT > umass0: BBB reset failed, TIMEOUT > umass0: BBB reset failed, TIMEOUT > umass0: BBB reset failed, TIMEOUT Please provide more information, such as dmesg including the controller you are using. Also, you don't state if this is USB2.0 device or a USB1.1 device. This makes it hard to debug and understand. Also, I would recomment you recompile your kernel w/ USB_DEBUG, and be prepared to turn on various sysctl's to provide more information. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Last inline offenders...
The following patch are my suggestion (already sent to maintainers)
for inlines to remove so we can get under the 2000 limit in GCC on
i386.
Index: dev/aic7xxx/aic79xx_inline.h
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_inline.h,v
retrieving revision 1.12
diff -u -r1.12 aic79xx_inline.h
--- dev/aic7xxx/aic79xx_inline.h28 Jun 2003 04:43:19 - 1.12
+++ dev/aic7xxx/aic79xx_inline.h23 Jul 2003 16:37:59 -
@@ -451,7 +451,7 @@
static __inline void ahd_set_sescb_qoff(struct ahd_softc *ahd, u_int value);
static __inline u_int ahd_get_sdscb_qoff(struct ahd_softc *ahd);
static __inline void ahd_set_sdscb_qoff(struct ahd_softc *ahd, u_int value);
-static __inline u_int ahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
+static u_int ahd_inb_scbram(struct ahd_softc *ahd, u_int offset);
static __inline u_int ahd_inw_scbram(struct ahd_softc *ahd, u_int offset);
static __inline uint32_t
ahd_inl_scbram(struct ahd_softc *ahd, u_int offset);
@@ -664,7 +664,7 @@
ahd_outb(ahd, SDSCB_QOFF+1, (value >> 8) & 0xFF);
}
-static __inline u_int
+static u_int
ahd_inb_scbram(struct ahd_softc *ahd, u_int offset)
{
u_int value;
Index: dev/drm/mga_state.c
===
RCS file: /home/ncvs/src/sys/dev/drm/mga_state.c,v
retrieving revision 1.6
diff -u -r1.6 mga_state.c
--- dev/drm/mga_state.c 25 Apr 2003 01:18:46 - 1.6
+++ dev/drm/mga_state.c 23 Jul 2003 18:33:33 -
@@ -71,7 +71,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g200_emit_context( drm_mga_private_t *dev_priv )
+static void mga_g200_emit_context( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_mga_context_regs_t *ctx = &sarea_priv->context_state;
@@ -97,7 +97,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_context( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_context( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_mga_context_regs_t *ctx = &sarea_priv->context_state;
@@ -128,7 +128,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
+static void mga_g200_emit_tex0( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[0];
@@ -159,7 +159,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_tex0( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[0];
@@ -203,7 +203,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_tex1( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_mga_texture_regs_t *tex = &sarea_priv->tex_state[1];
@@ -244,7 +244,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
+static void mga_g200_emit_pipe( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
unsigned int pipe = sarea_priv->warp_pipe;
@@ -274,7 +274,7 @@
ADVANCE_DMA();
}
-static __inline__ void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
+static void mga_g400_emit_pipe( drm_mga_private_t *dev_priv )
{
drm_mga_sarea_t *sarea_priv = dev_priv->sarea_priv;
unsigned int pipe = sarea_priv->warp_pipe;
Index: dev/drm/r128_state.c
===
RCS file: /home/ncvs/src/sys/dev/drm/r128_state.c,v
retrieving revision 1.6
diff -u -r1.6 r128_state.c
--- dev/drm/r128_state.c25 Apr 2003 01:18:46 - 1.6
+++ dev/drm/r128_state.c23 Jul 2003 18:33:33 -
@@ -98,7 +98,7 @@
ADVANCE_RING();
}
-static __inline__ void r128_emit_context( drm_r128_private_t *dev_priv )
+static void r128_emit_context( drm_r128_private_t *dev_priv )
{
drm_r128_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_r128_context_regs_t *ctx = &sarea_priv->context_state;
@@ -140,7 +140,7 @@
ADVANCE_RING();
}
-static __inline__ void r128_emit_masks( drm_r128_private_t *dev_priv )
+static void r128_emit_masks( drm_r128_private_t *dev_priv )
{
drm_r128_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_r128_context_regs_t *ctx = &sarea_priv->context_state;
@@ -174,7 +174,7 @@
ADVANCE_RING();
}
-static __inline__ void r128_emit_tex0( drm_r128_private_t *dev_priv )
+static void r128_emit_tex0( drm_r128_private_t *dev_priv )
{
drm_r128_sarea_t *sarea_priv = dev_priv->sarea_priv;
drm_r128_context_regs_t *ctx = &sa
Re: FreeBSD 5.1-R kernel panic
Stephane Raimbault wrote: Hi Thanks for your response, I do not have PAE enabled... I've been hesitant of turning it on, I'm not sure if it's too stable, I noticed that the asr driver is in the nodriver list in the PAE kernel config file and I use the asr driver for my Adaptec 2015S raid card. If you think its safe to enable PAE with my current setup, please let me know, I do have 2 more gig's of ram in this particular box that I'd like to enable if it doesn't compromise system stability. The asr(4) driver will likely not operate correctly in a PAE environment. There is no estimated time frame for fixing this either. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Mon, 21 Jul 2003, Bjoern A. Zeeb wrote: > Thanks. This works fine. Is there any "global" solution to the problem > so that I won't need to patch again the time 5.2R comes out ? Smells like a good candiate for a TUNABLE. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SMPng status?
Out of curiosity I was wondering what the SMPng status was? I have heard it's not fully implemented due to KSE/libthr not fully implemented. I was wondering if this was incorrect information or what? The reason i'm asking is there is a Dual P2-450 here that i'm trying to decide what to install on it. Thus SMPng becomes the question do i run -CURRENT or 4.8 or do something more evil? Any ideas? -- "I think we ought to be out there doing what we do best - making large holes in other people's countries." - George Carlin signature.asc Description: This is a digitally signed message part ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fun with 'fdisk -B -b /boot/boot0 ad0'
Greetings- I've got a laptop which I dualboot between -CURRENT and W2k. I recently had to reinstall W2k, and in the process it eliminated my MBR. I can successfully boot into FBSD by using a boot floppy and telling it to boot the kernel from the hard drive, but this is, well, kludgy. Checking the handbook, I found the entry on how to reinstall the MBR. So, I did a 'fdisk -B -b /boot/boot0 ad0'. The FreeBSD boot program came back, however, when I attempt to load FreeBSD, it merely beeps at me. It will, however, boot into W2k. I've tried supping, rebuilding the boot blocks (cd src/sys/boot; make install; fdisk -B -b /boot/boot0 ad0; disklabel -B ad0s2) with no success. I was hoping that someone might have an idea, as I've exhausted all of mine for the time being. Cheers, Ryan T. Dean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
We have ath, now what about Broadcom?
Folks, Okay, so now I just figured out what the "ath" driver is. Sigh... Of course, I find this out through searching for open source drivers for the Broadcom chipset as used in the Linksys WPC54G cardbus device, which I happen to have just bought. I've already done quite a bit of Googling and searching through the archives, and I haven't found anything obviously relevant to the issue of drivers for the Broadcom chipset, at least not anything recent. I did find a lot of old references to drivers for this chipset in the April timeframe, mostly having to do with people discovering that Linksys was shipping access points & routers using this chipset, using Linux for MIPS and BusyBox, but not providing the drivers themselves under their GPL obligations. Can anyone provide some pointers or links that would bring me up-to-date on the current state of affairs on this subject, especially as it related to FreeBSD or *BSD in general? Thanks! -- 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(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fuword(), suword(), etc.
I'd like to have a "suptr and fuptr" to be able to save and read user pointers in a "machine independent" manner.. at the moment ia need to know the size of a pointer and select the appropriate 32 or 64 version.. It would jus tbe another ENTRY files in support.[sS] alongside teh appropriate sized entry for each architecture so it wouldn't 'cost' anything.. for i386 it would be an alternate name for fuword32() and suword32() I'm not sure what it would be on other architectures comments? Anyone think this is a terribel idea? I need it to save pointers to user space in the KSE MI code to set up the "completed" list etc. Currently we use "suword()" etc. but I'd prefer something explicitly correct for a user pointer. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
still data corruption with 5.1-R on Intel Pentium 4
There have been threads about data corruption in RAM on P4 and other i386 machines on this list. I also observed the problem, on my laptop with 5.0-R. It seemed to go away with 5.1-R, on the laptop. Recently I upgraded my home PC which is a P4 2.0A from 4.8-R to 5.1-R. No problems at first. Until I ran "portsdb -Uu". I got a couple mysterious SIG4 and SIG11. Just to be sure I rebooted and tried again, same result. I rebooted another time, this time with ACPI disabled, and tried again, still the same. Then I rebuilt my kernel with options DISABLE_PSE and DISABLE_PG_G, as suggested by Terry in the old threads: Bingo, everything is fine now, no more SIG4 or SIG11 during portsdb -Uu. It seems the workarounds that we have in 5.1-R are not effective enough. What do you think? -- Regards, Georg. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
> Date: Wed, 23 Jul 2003 23:32:13 +0200 > From: Brad Knowles <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Folks, > > Okay, so now I just figured out what the "ath" driver is. Sigh... > > Of course, I find this out through searching for open source > drivers for the Broadcom chipset as used in the Linksys WPC54G > cardbus device, which I happen to have just bought. > > > I've already done quite a bit of Googling and searching through > the archives, and I haven't found anything obviously relevant to the > issue of drivers for the Broadcom chipset, at least not anything > recent. > > I did find a lot of old references to drivers for this chipset in > the April timeframe, mostly having to do with people discovering that > Linksys was shipping access points & routers using this chipset, > using Linux for MIPS and BusyBox, but not providing the drivers > themselves under their GPL obligations. > > > Can anyone provide some pointers or links that would bring me > up-to-date on the current state of affairs on this subject, > especially as it related to FreeBSD or *BSD in general? The folks at Broadcom have not been willing to release any information on their 800.11g chips for fear of violating FCC regs. The required NDA would prohibit the release of the source. You can program both the transmit power and frequency if you have this. (I make no claim as to whether their concerns have any validity.) For that reason there has been no open-source support for these chips. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
On Wed, Jul 23, 2003 at 02:48:41PM -0700, Julian Elischer wrote: > > I'd like to have a "suptr and fuptr" to be able to save and read > user pointers in a "machine independent" manner.. Sounds good to me. > for i386 it would be an alternate name for fuword32() and suword32() > I'm not sure what it would be on other architectures fuword64 and suword64. PowerPC is like i386. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
> > Folks, > > > > Okay, so now I just figured out what the "ath" driver is. Sigh... > > > > Of course, I find this out through searching for open source > > drivers for the Broadcom chipset as used in the Linksys WPC54G > > cardbus device, which I happen to have just bought. > > > > > > I've already done quite a bit of Googling and searching through > > the archives, and I haven't found anything obviously relevant to the > > issue of drivers for the Broadcom chipset, at least not anything > > recent. > > > > I did find a lot of old references to drivers for this chipset in > > the April timeframe, mostly having to do with people discovering that > > Linksys was shipping access points & routers using this chipset, > > using Linux for MIPS and BusyBox, but not providing the drivers > > themselves under their GPL obligations. > > > > > > Can anyone provide some pointers or links that would bring me > > up-to-date on the current state of affairs on this subject, > > especially as it related to FreeBSD or *BSD in general? > > The folks at Broadcom have not been willing to release any information > on their 800.11g chips for fear of violating FCC regs. The required > NDA would prohibit the release of the source. You can program > both the transmit power and frequency if you have this. (I make no > claim as to whether their concerns have any validity.) > > For that reason there has been no open-source support for these chips. Why would Broadcom be scared? Obviously it's the _driver_ that controls the power/freq output of the chip, so the responsibility of staying within FCC regs is that of the driver authors. Of course, the "no warranty" aspects of open source drivers turns a blind eye to liability, but would things really come back to Broadcom? -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
> From: "Matthew Emmerton" <[EMAIL PROTECTED]> > Date: Wed, 23 Jul 2003 18:21:23 -0400 > > > The folks at Broadcom have not been willing to release any information > > on their 800.11g chips for fear of violating FCC regs. The required > > NDA would prohibit the release of the source. You can program > > both the transmit power and frequency if you have this. (I make no > > claim as to whether their concerns have any validity.) > > > > For that reason there has been no open-source support for these chips. > > Why would Broadcom be scared? Obviously it's the _driver_ that controls the > power/freq output of the chip, so the responsibility of staying within FCC > regs is that of the driver authors. Of course, the "no warranty" aspects of > open source drivers turns a blind eye to liability, but would things really > come back to Broadcom? The logic is simple. the FCC hold the manufacturer responsible for improper RF from any product. The Broadcom chip makes it easy to generate illegal RF if you know where to poke. They don't care about a driver doing the right thing. They worry that, should the information become public, they can be held in violation as the manufacturer if someone uses that information to move the output to another frequency. Broadcom uses the secrecy of this information to claim compliance and without it, they could not make the chip. Once again, IANAL and I can't speak to the validity of this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
On Wed, Jul 23, 2003 at 06:21:23PM -0400, Matthew Emmerton wrote: > > > Folks, ... > > > Can anyone provide some pointers or links that would bring me > > > up-to-date on the current state of affairs on this subject, > > > especially as it related to FreeBSD or *BSD in general? > > > > The folks at Broadcom have not been willing to release any information > > on their 800.11g chips for fear of violating FCC regs. The required > > NDA would prohibit the release of the source. You can program > > both the transmit power and frequency if you have this. (I make no > > claim as to whether their concerns have any validity.) > > > > For that reason there has been no open-source support for these chips. > > Why would Broadcom be scared? Obviously it's the _driver_ that controls the > power/freq output of the chip, so the responsibility of staying within FCC > regs is that of the driver authors. Of course, the "no warranty" aspects of > open source drivers turns a blind eye to liability, but would things really > come back to Broadcom? Simple: ETOOMANYCORPORATELAWYERS is most likely the culprit.. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
On Wed, Jul 23, 2003 at 06:21:23PM -0400, Matthew Emmerton wrote: > Why would Broadcom be scared? Obviously it's the _driver_ that controls the > power/freq output of the chip, so the responsibility of staying within FCC > regs is that of the driver authors. Of course, the "no warranty" aspects of > open source drivers turns a blind eye to liability, but would things really > come back to Broadcom? It's not sufficent for a manufacture of RF equipment to say "don't do that". They have to take real, more or less working steps to keep you from doing things you aren't supposed to do. This is why the Linksys link boosters were pulled. FWIW, there is a solution to this which Sam used to when implementing ath(4). That is to implement a binary-only hardware access layer, ath_hal(4), that keeps you from doing things you aren't supposed to with the highly programable chips. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Buildworld /rescue failures in 5.1
I am not much of a makefile expert, but I have been trying various changes to see if I could fix the problem with building /rescue. On my system, a buildworld will always fail if I specify '-j'. It is time-consuming to try things, because it takes a while to do a whole buildworld. Today it occurred to me that I could probably make things go much faster if I didn't do the whole buildworld. And indeed, it turns out that I get the same 'make' error if I use: rm -Rf /usr/obj/usr/src/* cd /usr/src/rescue make -j5 obj make -j5 includes make -j5 depend make -j5 all Where that error is: make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error *** Error code 2 1 error The nice thing about this is that it only takes three minutes to get to that error, instead of the seventy minutes that it takes when doing it as part of buildworld. And if I drop the '-j5', then the error does not come up. This also suggests I could probably get away with: cd /usr/src make -j5 -DNO_RESCUE buildworld cd /usr/src/rescue make obj includes && make depend && make all -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Remove "options HW_WDOG"?
While working on my software watchdog, it has come to my attention that the "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually use this code, or can I purge it in favor of the software watchdog? /usr/src/sys$ find . -type f |xargs grep HW_WDOG ./conf/NOTES:optionsHW_WDOG ./conf/options:HW_WDOG ./kern/kern_shutdown.c:#ifdef HW_WDOG ./kern/kern_shutdown.c:#endif /* HW_WDOG */ All the bit in kern/kern_shutdown.c does is: watchdog_tickle_fn wdog_tickler = NULL; And I can't find that being used anywhere. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.sean-kelly.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: still data corruption with 5.1-R on Intel Pentium 4
> There have been threads about data corruption in RAM on P4 and other > i386 machines on this list. I also observed the problem, on my laptop > with 5.0-R. It seemed to go away with 5.1-R, on the laptop. > > Recently I upgraded my home PC which is a P4 2.0A from 4.8-R to 5.1-R. > No problems at first. > > Until I ran "portsdb -Uu". I got a couple mysterious SIG4 and SIG11. > Just to be sure I rebooted and tried again, same result. I rebooted > another time, this time with ACPI disabled, and tried again, still the > same. > > Then I rebuilt my kernel with options DISABLE_PSE and DISABLE_PG_G, as > suggested by Terry in the old threads: Bingo, everything is fine now, no > more SIG4 or SIG11 during portsdb -Uu. > > It seems the workarounds that we have in 5.1-R are not effective enough. > What do you think? I'm having some SIG4 too when doing the massive operation "portsdb -Uu". I don't mind too much because it's usually only two make process which die however I would like to know if DISABLE_PSE and DISABLE_PG_G impacts performance or not and if it's specific to BSD. I tried lately rebuilding world and kernel with CPU_TYPE=p3 in order to be sure it was not due to gcc over-optimizing for p4, we will see. Anthony. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: still data corruption with 5.1-R on Intel Pentium 4
On Wed, 24 Jul 2003, Georg-W. Koltermann wrote: > There have been threads about data corruption in RAM on P4 and other > i386 machines on this list. I also observed the problem, on my laptop > with 5.0-R. It seemed to go away with 5.1-R, on the laptop. > > Recently I upgraded my home PC which is a P4 2.0A from 4.8-R to 5.1-R. > No problems at first. > > Until I ran "portsdb -Uu". I got a couple mysterious SIG4 and SIG11. > Just to be sure I rebooted and tried again, same result. I rebooted > another time, this time with ACPI disabled, and tried again, still the > same. > > Then I rebuilt my kernel with options DISABLE_PSE and DISABLE_PG_G, as > suggested by Terry in the old threads: Bingo, everything is fine now, no > more SIG4 or SIG11 during portsdb -Uu. > > It seems the workarounds that we have in 5.1-R are not effective enough. > What do you think? DISABLE_PSE and DISABLE_PG_G fixes all of the machines that I've seen with random segvs (And for the record, they've all been Pentium 4s). I find it ridiculous that chip vendors require NDAs to find out about _faults_ in the chips they've sold you. It's bad enough that these faults made it through QA and they're not offering replacement chips, but not allowing information about the problem to circulate so that appropriate workarounds can be made is immoral. My thoughts, Andy > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld /rescue failures in 5.1
At 6:41 PM -0400 7/23/03, Garance A Drosihn wrote: Where that error is: make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error *** Error code 2 1 error Well, that isn't always the error message, but it's always something similar to that. Now that it takes me only a few minutes to test things, I think I'm making some kind of headway. I redid the making of rescue with '-j2', and got the error make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/gnu/usr.bin/tar/addext.o. Stop I then compared the files in the directory /usr/obj/usr/src/.../usr.bin/tar between the attempt which worked, and the attempt which failed. The attempt which worked had a '.depend' file which did not exist in the attempt which failed. Ie, make trying to build addext.o before the .depend file has shown up for anything in 'tar'. In the attempt which works, that .depend file includes: addext.o: /usr/src/contrib/tar/lib/addext.c \ /usr/src/gnu/usr.bin/tar/config.h /usr/include/paths.h \ /usr/include/sys/cdefs.h /usr/include/limits.h \ /usr/include/sys/limits.h /usr/include/machine/_limits.h \ /usr/include/sys/syslimits.h /usr/include/sys/types.h \ /usr/include/machine/endian.h /usr/include/sys/_types.h \ /usr/include/machine/_types.h /usr/include/sys/select.h \ /usr/include/sys/_sigset.h /usr/include/sys/_timeval.h \ /usr/include/sys/timespec.h /usr/include/string.h \ /usr/include/strings.h /usr/include/unistd.h /usr/include/sys/unistd.h \ /usr/include/errno.h /usr/src/contrib/tar/lib/backupfile.h \ /usr/src/contrib/tar/lib/dirname.h So it is easy to image that this .depend file is crucial to successfully making addext.o. The .depend file is apparently created by /usr/obj/usr/src/rescue/rescue/rescue.mk and that in turn says it is generated from rescue.conf by crunchgen 0.2. The rescue.mk file includes the rule: tar_make: (cd $(tar_SRCDIR) && \ $(MAKE) $(BUILDOPTS) $(tar_OPTS) depend &&\ $(MAKE) $(BUILDOPTS) $(tar_OPTS) $(tar_OBJS)) and my guess is that construct is not '-j' safe. I have no idea how to fix that, or even if I'm on the right track, but perhaps the above will be useful to someone who understands parallel makes more than I do... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-07-23 22:16:58 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-23 22:16:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-23 22:18:51 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> 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/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-23 23:41:13 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Jul 23 23:41:13 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common --param max-inline-insns-single=2500 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/firewire/fwcrom.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common --param max-inline-insns-single=2500 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/firewire/fwdev.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common --param max-inline-insns-single=2500 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/firewire/fwdma.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common --param max-inline-insns-single=2500 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/firewire/fwmem.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/d
Re: Buildworld /rescue failures in 5.1
On Wed, Jul 23, 2003 at 07:41:18PM -0400, Garance A Drosihn wrote: > > So it is easy to image that this .depend file is crucial to > successfully making addext.o. > > The .depend file is apparently created by > /usr/obj/usr/src/rescue/rescue/rescue.mk > > and that in turn says it is generated from rescue.conf > by crunchgen 0.2. The rescue.mk file includes the rule: > > tar_make: > (cd $(tar_SRCDIR) && \ > $(MAKE) $(BUILDOPTS) $(tar_OPTS) depend &&\ > $(MAKE) $(BUILDOPTS) $(tar_OPTS) $(tar_OBJS)) > > and my guess is that construct is not '-j' safe. > > I have no idea how to fix that, or even if I'm on the right > track, but perhaps the above will be useful to someone who > understands parallel makes more than I do... I don't see how this construct cannot be parallel make safe. The && requires that the third line check the result of the second before continuing. It doesn't make sense. -gordon pgp0.pgp Description: PGP signature
Re: Buildworld /rescue failures in 5.1
At 4:44 PM -0700 7/23/03, Gordon Tetlow wrote: On Wed, Jul 23, 2003, Garance A Drosihn wrote: > > The .depend file is apparently created by > /usr/obj/usr/src/rescue/rescue/rescue.mk > and that in turn says it is generated from rescue.conf by crunchgen 0.2. The rescue.mk file includes the rule: tar_make: (cd $(tar_SRCDIR) && \ $(MAKE) $(BUILDOPTS) $(tar_OPTS) depend &&\ $(MAKE) $(BUILDOPTS) $(tar_OPTS) $(tar_OBJS)) and my guess is that construct is not '-j' safe. I have no idea how to fix that, or even if I'm on the right track, but perhaps the above will be useful to someone who understands parallel makes more than I do... I don't see how this construct cannot be parallel make safe. The && requires that the third line check the result of the second before continuing. It doesn't make sense. Yeah, I don't know how these pieces all come together (or don't come together, as the case may be). Nevertheless, it is true that make is apparently trying a 'make addext.o' before that .depend file exists. Perhaps this is a bug, or maybe I'm just barking up the wrong tree... I'm going to try a few more tests, and see if I can make some sense out of this. Given that 'make buildworld' is going to effectively do: cd /usr/src/rescue make obj [...other stuff...] cd /usr/src/rescue make includes [...other stuff...] cd /usr/src/rescue make depend [...other stuff...] it would be nice if *that* 'make depend' could result in all of these .depend files being created. That is clearly not the case at the moment. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld /rescue failures in 5.1
At 4:44 PM -0700 7/23/03, Gordon Tetlow wrote: I don't see how this construct cannot be parallel make safe. The && requires that the third line check the result of the second before continuing. It doesn't make sense. Oops, my last reply got away from me before I was done... Anyway, I added some 'echo's to /usr/share/mk/bsd.dep.mk: beforedepend: echo "`date` Starting make depend in `pwd`" >> /tmp/buildrescue-log and afterdepend: echo "`date` Finished make depend in `pwd`" >> /tmp/buildrescue-log The make again failed with: make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/gnu/usr.bin/tar/addext.o. Stop And the last lines in the log were: Wed Jul 23 20:08:06 EDT 2003 Starting make depend in /usr/obj/usr/src/rescue/rescue/usr/src/gnu/usr.bin/gzip Wed Jul 23 20:08:07 EDT 2003 Finished make depend in /usr/obj/usr/src/rescue/rescue/usr/src/gnu/usr.bin/gzip Wed Jul 23 20:08:09 EDT 2003 Starting make depend in /usr/obj/usr/src/rescue/rescue/usr/src/gnu/usr.bin/tar So indeed, that 'make depend' had not finished before the 'make' for the object had started. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remove "options HW_WDOG"?
this code WAS used in the interjet. We had modules that linked in and just needed somewhere to hook into.. the hardware watchdog was held off by our software, but we needed to add code to the core-dump routines to routinely call the watchdog hold-off or we could never get a coredump because the watchdog would always go off before the dump was completed. I doubt it is used by anyone any more but It's good that you asked.. I did notice some people were working on the watchdog support for the chipsets that have a watchdog in them so I guess they wil have all their own entrypoints. Julian On Wed, 23 Jul 2003, Sean Kelly wrote: > While working on my software watchdog, it has come to my attention that the > "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually > use this code, or can I purge it in favor of the software watchdog? > > /usr/src/sys$ find . -type f |xargs grep HW_WDOG > ./conf/NOTES:optionsHW_WDOG > ./conf/options:HW_WDOG > ./kern/kern_shutdown.c:#ifdef HW_WDOG > ./kern/kern_shutdown.c:#endif /* HW_WDOG */ > > All the bit in kern/kern_shutdown.c does is: > > watchdog_tickle_fn wdog_tickler = NULL; > > And I can't find that being used anywhere. > > -- > Sean Kelly | PGP KeyID: D2E5E296 > [EMAIL PROTECTED] | http://www.sean-kelly.org/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
psmintr: discard a byte (1) [moused issues]
Hi all, I have a relatively current repository (CTM delta cvs-cur 9444), and have just built world/kernel. I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel) I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Jul 23 17:01:35 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:01:35 hostname kernel: psmintr: discard a byte (1). Jul 23 17:01:36 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:01:36 hostname kernel: psmintr: discard a byte (2). Jul 23 17:01:36 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:01:36 hostname kernel: psmintr: discard a byte (3). Jul 23 17:01:36 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:01:36 hostname kernel: psmintr: re-enable the mouse. Jul 23 17:02:01 hostname kernel: psmintr: delay too long; resetting byte count Jul 23 17:02:02 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:02:02 hostname kernel: psmintr: discard a byte (1). Jul 23 17:02:02 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:02:02 hostname kernel: psmintr: discard a byte (2). Jul 23 17:02:03 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:02:03 hostname kernel: psmintr: discard a byte (3). Jul 23 17:02:04 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:02:04 hostname kernel: psmintr: re-enable the mouse. Jul 23 17:02:06 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:02:06 hostname kernel: psmintr: discard a byte (5). Jul 23 17:02:06 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:02:06 hostname kernel: psmintr: discard a byte (6). Jul 23 17:04:10 hostname kernel: psmintr: delay too long; resetting byte count Jul 23 17:04:41 hostname kernel: psmintr: delay too long; resetting byte count Jul 23 17:04:42 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:04:42 hostname kernel: psmintr: discard a byte (1). Jul 23 17:04:42 hostname kernel: psmintr: out of sync ( != 0008). Jul 23 17:04:42 hostname kernel: psmintr: discard a byte (2). Jul 23 17:04:44 hostname kernel: psmintr: out of sync ( != 0008). moused is running with the following: "moused -p /dev/psm0 -t microsoft" The mouse is a Microsoft IntelliMouse. If I boot the same machine into -STABLE this does *not* happen. I have tryed running moused with different protocols etc without any luck. Can anyone help me solve this problem ? I have to run -STABLE if I can't solve this problem, so any help would be appreciated. Thanks - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld /rescue failures in 5.1
At 8:14 PM -0400 7/23/03, Garance A Drosihn wrote: So indeed, that 'make depend' had not finished before the 'make' for the object had started. I was going to do some debugging of what 'make' is doing, but it looks like crunchgen gets confused if make has any kind of debugging flags turned on. However, I have to get back to my real-job work before my manager clobbers me, so this is probably as far as I'm going to take this for now. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: still data corruption with 5.1-R on Intel Pentium 4
On Wed, Jul 23, 2003 at 07:32:34PM -0400, Andre Guibert de Bruet wrote: > DISABLE_PSE and DISABLE_PG_G fixes all of the machines that I've seen with > random segvs (And for the record, they've all been Pentium 4s). Not for me. I mostly get NFS corruption though. Kris pgp0.pgp Description: PGP signature
Re: SMPng status?
On Wed, Jul 23, 2003 at 02:06:24PM -0700, Scott M. Likens wrote: > Out of curiosity I was wondering what the SMPng status was? > > I have heard it's not fully implemented due to KSE/libthr not fully > implemented. > > I was wondering if this was incorrect information or what? That's not really correct. The SMP threading libraries are one aspect of SMP development work in 5.x, and modulo bugs, optimization, architectural issues and non-i386 platform support they work. The major aspect of SMP development is kernel subsystem locking, which is not yet complete, and will not be for some time. If you're willing to deal with the usual caveats of running -CURRENT, then by all means do so :-) Kris pgp0.pgp Description: PGP signature
Re: psmintr: discard a byte (1) [moused issues]
On 24-Jul-2003 Wilkinson,Alex wrote: | Hi all, | | I have a relatively current repository (CTM delta cvs-cur 9444), and | have just built | world/kernel. | | | ... | | moused is running with the following: | | "moused -p /dev/psm0 -t microsoft" | | The mouse is a Microsoft IntelliMouse. For PS/2 mice you should only use PS/2 or auto as the type. | | If I boot the same machine into -STABLE this does *not* happen. | | I have tryed running moused with different protocols etc without any | luck. | | Can anyone help me solve this problem ? | Can you add options PSM_DEBUG=2 to your kernel config and recompile, then do a verbose boot (boot -v) and send me the output? Mike -- Mike Heffner <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> pgp0.pgp Description: PGP signature
ums panic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After a fresh cvsup today, I was playing around with my mouse and managed to
get a panic from ums. I loaded usb/ums from a kernel module, started usbd,
(mouse is working), unload ums, load ums -> panic so:
kldload ums
usbd
kldunload ums
kldload ums (panic)
The mouse was plugged in the entire time.
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc01e62e2 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01e6617 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0304406 in trap_fatal (frame=0xcd338ac8, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4 0xc03040a2 in trap_pfault (frame=0xcd338ac8, usermode=0, eva=522)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc0303c65 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1024395648, tf_esi =
- -1024395648, tf_ebp = -852260088, tf_isp = -852260108, tf_ebx = -842240968,
tf_edx = -1070073024, tf_ecx = -1015545712, tf_eax = 518, tf_trapno = 12,
tf_err = 0, tf_eip = -1015634330, tf_cs = 8, tf_eflags = 66054, tf_esp =
- -852260052, tf_ss = -1029324969}) at /usr/src/sys/i386/i386/trap.c:420
#6 0xc02f4df8 in calltrap () at {standard input}:102
#7 0xc2a5bf57 in ums_match (self=0x0) at /usr/src/sys/dev/usb/ums.c:176
#8 0xc01fece8 in DEVICE_PROBE (dev=0xc2f0f680) at device_if.h:22
#9 0xc01fcb28 in device_probe_child (dev=0x0, child=0xc2f0f680)
at /usr/src/sys/kern/subr_bus.c:1052
#10 0xc01fd32d in device_probe_and_attach (dev=0xc2f0f680)
at /usr/src/sys/kern/subr_bus.c:1435
#11 0xc01fdd9e in bus_generic_driver_added (dev=0xc2f0f680, driver=0x0)
at /usr/src/sys/kern/subr_bus.c:1859
#12 0xc01ff0af in BUS_DRIVER_ADDED (_dev=0xc327ab80, _driver=0x0)
at /usr/src/sys/kern/subr_bus.c:587
#14 0xc01fe835 in driver_module_handler (mod=0xc2a9c140, what=0,
arg=0xc2a5e440) at /usr/src/sys/kern/subr_bus.c:2273
#15 0xc01dcbe1 in module_register_init (arg=0xc2a5e458)
at /usr/src/sys/kern/kern_module.c:108
#16 0xc01d74c0 in linker_file_sysinit (lf=0x0)
at /usr/src/sys/kern/kern_linker.c:192
#17 0xc01d7811 in linker_load_file (filename=0xc2474500 "/boot/kernel/ums.ko",
result=0xcd338ca4) at /usr/src/sys/kern/kern_linker.c:357
#18 0xc01d9d67 in linker_load_module (kldname=0xc036a7f0 "¯\2302À §6ÀÈ",
modname=0xc2474500 "/boot/kernel/ums.ko", parent=0x0, verinfo=0x0,
lfpp=0xcd338cd0) at /usr/src/sys/kern/kern_linker.c:1670
#19 0xc01d82f3 in kldload (td=0xc245fbe0, uap=0x0)
at /usr/src/sys/kern/kern_linker.c:773
#20 0xc03046d3 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077937308,
tf_ebp = -1077937352, tf_isp = -852259468, tf_ebx = 0, tf_edx = 134576680,
tf_ecx = 0, tf_eax = 304, tf_trapno = 12, tf_err = 2, tf_eip = 134513967,
tf_cs = 31, tf_eflags = 531, tf_esp = -1077937396, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1008
#21 0xc02f4e4d in Xint0x80_syscall () at {standard input}:144
- --
Anish Mistry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/H0IXxqA5ziudZT0RAttYAJ9VdGWNxgd43i09RAX2aHnAig7c6gCePl7o
m7+VihZ5UkSwcuDd6WRrBP4=
=xYC7
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
3Com 3C9340 (3C200) support
I own an Abit IS7-G which includes an intergrated 3Com 3C940 card currently not supported in any FreeBSD branch to my knowledge. Some people said that the nic could world with the Tigon III driver but I haven't been able to get it to work with it during install. Are there any plans or projects to get this card supported in the near future? A Linux driver is provided by 3Com. Thanks in advance for your time. -Damian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
At Wed, 23 Jul 2003 13:31:31 -0700 (PDT),
Doug White wrote:
>
> On Mon, 21 Jul 2003, Bjoern A. Zeeb wrote:
>
> > Thanks. This works fine. Is there any "global" solution to the problem
> > so that I won't need to patch again the time 5.2R comes out ?
>
> Smells like a good candiate for a TUNABLE.
Are they the following patches?
--- /sys/dev/pci/pci.c.orig Tue Jul 1 23:08:32 2003
+++ /sys/dev/pci/pci.c Thu Jul 24 13:17:03 2003
@@ -177,6 +177,12 @@
enable these bits correctly. We'd like to do this all the time, but there\n\
are some peripherals that this causes problems with.");
+static int pci_enable_rerouting = 1;
+TUNABLE_INT("hw.pci.enable_rerouting", (int *)&pci_enable_rerouting);
+SYSCTL_INT(_hw_pci, OID_AUTO, enable_rerouting, CTLFLAG_RW,
+&pci_enable_rerouting, 1,
+"Enable try to re-route interrupts.");
+
/* Find a device_t by bus/slot/function */
device_t
@@ -801,6 +807,9 @@
if (cfg->intpin > 0 && PCI_INTERRUPT_VALID(cfg->intline)) {
#if defined(__ia64__) || (defined(__i386__) && !defined(SMP))
+ if (!pci_enable_rerouting){
+ goto nottry;
+ }
/*
* Try to re-route interrupts. Sometimes the BIOS or
* firmware may leave bogus values in these registers.
@@ -812,6 +821,7 @@
pci_write_config(dev, PCIR_INTLINE, irq, 1);
cfg->intline = irq;
} else
+nottry:
#endif
irq = cfg->intline;
resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ums panic
Anish Mistry wrote this message on Wed, Jul 23, 2003 at 22:18 -0400: > After a fresh cvsup today, I was playing around with my mouse and managed to > get a panic from ums. I loaded usb/ums from a kernel module, started usbd, > (mouse is working), unload ums, load ums -> panic so: There are known issues w/ loading/unloading/loading USB modules. Don't do that (unless you are debuging the problem). Feel free to research why this is doing it. :) I'll gladly review and commit any patches you generate for this problem. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
OT: X aperture
Hello again! Sorry for trolling. I have just found one more way to have X and seculevel coexisting. It's applicable for desktops mostly.Here's the trick: Start the system with seculevel "-1", run startx and then type '/sbin/sysctl -w kern.securelevel=1' in a terminal. The last requires as all know requires root privileges or sudo. Thanks for your patience, Dimitar Vassilev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remove "options HW_WDOG"?
On Wed, 23 Jul 2003, Sean Kelly wrote: > While working on my software watchdog, it has come to my attention that the > "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually > use this code, or can I purge it in favor of the software watchdog? > > /usr/src/sys$ find . -type f |xargs grep HW_WDOG > ./conf/NOTES:optionsHW_WDOG > ./conf/options:HW_WDOG > ./kern/kern_shutdown.c:#ifdef HW_WDOG > ./kern/kern_shutdown.c:#endif /* HW_WDOG */ > > All the bit in kern/kern_shutdown.c does is: > > watchdog_tickle_fn wdog_tickler = NULL; > > And I can't find that being used anywhere. watchdog_tickle_fn wdog_tickler is only used in the wd driver, which is still undead in RELENG_4. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fun with 'fdisk -B -b /boot/boot0 ad0'
>I was hoping that someone might have an idea, as >I've exhausted all of mine for the time being. Boot0 is just a boot menu whose contents are in sector0 of your hard disk. Another boot block (most likely the contents of boot1) should located at or near the beginning of your freebsd slice. This is done with the -B option of bsdlabel (formerly disklabel). For all I know something to the effect of typing "bsdlabel -e -B ad0s2_or_whateveryourfbsdsliceis" and then exiting without making any changes to the displayed table of fbsd partitions may do the trick. Hopefully some experts will chime in with better suggestions if I'm dead wrong. Certainly, the bsdlabel man page is your friend. In any case, I once botched gentoo linux on a neighboring slice and corrupted my freebsd -CURRENT disklabel so that I couldn't even boot by way of a floppy, but with the disklabel (bsdlabel) command on a 5.x install cd, I successfully created an identical new one right over the old corrupted one and I didn't lose any data. "Your mileage may vary." Another (possibly easier, safer) option is set up and use the windows boot manager to choose between w2000 or freebsd. You need to copy /boot/boot1 over to your windows partition (give it a unique name like "myfbsdboot.bin") and then add a few lines to C:\BOOT.INI to the effect of: C:\myfbsdboot.bin="FreeBSD5.x_CURRENT Partition" Put it after the line that mentions the windows boot block, which ought to look similar to this: [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Media Center Edition" /fastdetect /noserialmice /sos There is some sort of wizard/menu in windows that can walk you through all this so that you don't have to pull up C:\boot.ini directly (or create one from scratch perhaps). Hope this helps. Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to provide useful debug info
Harald Schmalzbauer wrote: > Bob Bishop wrote: > > See > > http://www.uk.freebsd.org/doc/en_US.ISO8859-1/books/developers-han > > dbook/kerneldebug.html, > > particularly 17.4 and 17.5 > > Thank you for that link, but that's far too complicated for me. I don't know > any of these gdb commands, I can just feed you with info. > > So as far as I understand, if I enter "trace" at any point when I see "db>" > that's what you need is it? The trace information that this will give is only marginally useful for debugging, and then only if the problem does not involve a dereference of a bad pointer or a lock inversion, or some other issue that would require eyballing a particular line of code and the code that surrounds it in order to find the problem. For anything more complicated than that, we need line numbers. There are three ways to get this from a crashed machine: 1) Remote source level debugging from another machine; this requires that you have a copy of the build tree for what's running on the machine that crashed 2) Local source level debugging using a crashdump; this requires that you enable crash dumps, and that you have a copy of the build tree for what's running on the machine that crashed 3) You must be running a -RELEASE, so that *we* have a copy of the build tree for what's running on the machine that crashed, and you must transcribe *exactly* all the information from the traceback Option 3 is nearly impossible, unless someone sends you a kernel to try and run, since the release distribution doesn't enable ddb at build time, and there's no way to enable it at boot time as a seperate option (but it works OK for Darwin, which provides a stack traceback by hexadecimal address, if you enable the verbose crash dumps at boot time). FreeBSD really needs to either ship with DDB enabled, provide a way for DDB to be enabled in a release at boot time, or find a way of providing a minimal stack traceback (even if it's just a list of hex addresses, like Darwin) at crash time. In any case, this will not help diagnose problems resulting from someone stomping memory and/or bad pointer dereferences, or those arising from missing locks, etc.. Your best bet, if you want useful help with a complex problem is to learn how to provide the more complicated crash information which is needed in order to remotely diagnose complex problems. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pnp code and irq 2 problem
Hi, Somewhere along the line the code in FreeBSD that maps irq 2 to irq 9 has gone away and a panic was added if one tries to use irq 2. This is all well and fine, except that the pnp code was not notified of this. :-) So if you have a pnp device that have irq 2 in its mask and FreeBSD then decides that irq 2 is a good irq to use for this device, you have an instant panic. I have worked around it with this crude patch below. Crude because: 1) I don't know if it should be an i386 only fix, and 2) I used 0x04 directly, maybe IRQ_SLAVE from i386/isa/icu.h or some other difine should be used? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Index: isa/pnpparse.c === RCS file: /home/ncvs/src/sys/isa/pnpparse.c,v retrieving revision 1.13 diff -u -r1.13 pnpparse.c --- isa/pnpparse.c 16 Oct 2002 09:07:30 - 1.13 +++ isa/pnpparse.c 19 Jun 2003 06:00:02 - @@ -110,7 +110,8 @@ if (bootverbose) pnp_printf(id, "adding irq mask %#02x\n", I16(res)); - config->ic_irqmask[config->ic_nirq] = I16(res); + config->ic_irqmask[config->ic_nirq] = I16(res) & + ~0x04; config->ic_nirq++; break; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 3Com 3C9340 (3C200) support
> I own an Abit IS7-G which includes an intergrated 3Com 3C940 card > currently not supported in any FreeBSD branch to my knowledge. Some > people said that the nic could world with the Tigon III driver but I > haven't been able to get it to work with it during install. Are there > any plans or projects to get this card supported in the near future? A > Linux driver is provided by 3Com. Thanks in advance for your time. In the next few days, I will be committing support for this chip to the OpenBSD sk driver. Our sk driver was based on the freebsd, so it will be simple to backport. Nathan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Possible problem with ACL masks and getfacl
Hi all, I'm not sure if this is a real problem or not, but if I set a group ACL on a file, and then set a mask, when running getfacl the group names are not listed. I'm running 5.1 RELEASE. The following sequence commands show the problem (I create a file, display the ACL, set a group ACL, display the ACL, set a mask, and then display the ACL again. The problem is with the final display - the group name is not displayed). # touch testfile # getfacl testfile #file:testfile #owner:0 #group:0 user::rw- group::r-- other::r-- # setfacl -m g:staff:rwx testfile # getfacl testfile #file:testfile #owner:0 #group:0 user::rw- group::r-- group:staff:rwx mask::rwx other::r-- # setfacl -m m::rx testfile # getfacl testfile #file:testfile #owner:0 #group:0 user::rw- group::r-- group::rwx # effective: r-x mask::r-x other::r-- Attached is a proposed patch to lib/libc/posix1e/acl_to_text.c to correct this problem. Please note that this patch has not been tested as the computer I'm testing on won't build world :( (cheap computer with cheap components). The source used is actually CURRENT as of Tuesday July 22nd. I admit that there may be a reason why the user name is not shown which I don't know about :). Feedback is greatly appreciated. Glen Gibb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Possible problem with ACL masks and getfacl (fwd)
Whoops - it helps if I attach the patch :)
Glen
-- Forwarded message --
Date: Thu, 24 Jul 2003 16:54:55 +1000 (EST)
From: Glen Gibb <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Possible problem with ACL masks and getfacl
Hi all,
I'm not sure if this is a real problem or not, but if I set a group
ACL on a file, and then set a mask, when running getfacl the group names
are not listed.
I'm running 5.1 RELEASE.
The following sequence commands show the problem (I create a file, display
the ACL, set a group ACL, display the ACL, set a mask, and then display
the ACL again. The problem is with the final display - the group name is
not displayed).
# touch testfile
# getfacl testfile
#file:testfile
#owner:0
#group:0
user::rw-
group::r--
other::r--
# setfacl -m g:staff:rwx testfile
# getfacl testfile
#file:testfile
#owner:0
#group:0
user::rw-
group::r--
group:staff:rwx
mask::rwx
other::r--
# setfacl -m m::rx testfile
# getfacl testfile
#file:testfile
#owner:0
#group:0
user::rw-
group::r--
group::rwx # effective: r-x
mask::r-x
other::r--
Attached is a proposed patch to lib/libc/posix1e/acl_to_text.c to correct
this problem. Please note that this patch has not been tested as the
computer I'm testing on won't build world :( (cheap computer with cheap
components). The source used is actually CURRENT as of Tuesday July
22nd.
I admit that there may be a reason why the user name is not shown
which I don't know about :).
Feedback is greatly appreciated.
Glen Gibb
--- /usr/src/lib/libc/posix1e/acl_to_text.c.origThu Jul 24 16:47:41 2003
+++ /usr/src/lib/libc/posix1e/acl_to_text.c Thu Jul 24 16:48:12 2003
@@ -177,9 +177,10 @@
effective_perm_buf);
if (error)
goto error_label;
- len = asprintf(&tmpbuf, "%sgroup::%s\t\t# "
+ len = asprintf(&tmpbuf, "%sgroup:%s:%s\t\t# "
"effective: %s\n",
- buf, perm_buf, effective_perm_buf);
+ buf, name_buf, perm_buf,
+ effective_perm_buf);
} else {
len = asprintf(&tmpbuf, "%sgroup:%s:%s\n", buf,
name_buf, perm_buf);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
