Re: Where was that iSCSI initiator?
On Thu, Oct 19, 2006 at 02:14:41AM +0200, Max Laier wrote: > On Thursday 19 October 2006 00:35, Ceri Davies wrote: > > Could anyone please let me know the status of the iSCSI initiator that > > was floated here some time ago? Is it in a commitable state and, if > > not, can I help with testing (we have some Netware targets)? > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-17.5.tar.bz2 is that the > one you were thinking about? That's the one. Thanks, Max. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpgWkVLaCR9e.pgp Description: PGP signature
Where was that iSCSI initiator?
Could anyone please let me know the status of the iSCSI initiator that was floated here some time ago? Is it in a commitable state and, if not, can I help with testing (we have some Netware targets)? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpxkCIdcZXJ9.pgp Description: PGP signature
Re: Using any network interface whatsoever
On Sat, Apr 08, 2006 at 05:42:13PM -0600, Scott Long wrote: > Ceri Davies wrote: > > >On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: > > > >>>>On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: > > > > > >>>>>For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, > >>>>>but I'd > >>>>>also like to have it try to configure whatever interfaces the machine > >>>>>happens to have via DHCP. > >>>>> > >>>>>Other than specifying ifconfig_0="DHCP" once for every possible > >>>>>value of > >>>>>, is there a mechanism to do this already? > >>>> > >>>>ifconfig_DEFAULT > >> > >>Well, the real question is why we force the details of driver names onto > >>users. Network and storage drivers are especially guilty of this, but > >>tty devices also are annoying. > > > > > >The current situation on BSD, where I can identify which interface is > >meant by its type, is definitely preferable to the Linux situation where > >eth0 may mean something different tomorrow depending on what is plugged > >in. > > > >Since we can rename devices arbitrarily, I don't really see a problem > >with respect to anything else. > > > >Ceri > > I'll say again, how does having em0, em1, em2, and em3 help me know what > is going on with each of those interfaces? Well it doesn't, but there is no way for the OS vendor to determine what you're doing. You're more than able to rename them to dmz0, world0 or whatever in order to reflect their real usage if you like. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpxxaANSPXAI.pgp Description: PGP signature
Re: Using any network interface whatsoever
On Sat, Apr 08, 2006 at 08:34:30AM -0600, Scott Long wrote: > >>On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: > >>>For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but > >>>I'd > >>>also like to have it try to configure whatever interfaces the machine > >>>happens to have via DHCP. > >>> > >>>Other than specifying ifconfig_0="DHCP" once for every possible > >>>value of > >>>, is there a mechanism to do this already? > >> > >>ifconfig_DEFAULT > > Well, the real question is why we force the details of driver names onto > users. Network and storage drivers are especially guilty of this, but > tty devices also are annoying. The current situation on BSD, where I can identify which interface is meant by its type, is definitely preferable to the Linux situation where eth0 may mean something different tomorrow depending on what is plugged in. Since we can rename devices arbitrarily, I don't really see a problem with respect to anything else. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpaF0iZFohHl.pgp Description: PGP signature
Re: Using any network interface whatsoever
On Fri, Apr 07, 2006 at 03:57:42PM -0700, Brooks Davis wrote: > On Fri, Apr 07, 2006 at 11:53:42PM +0100, Ceri Davies wrote: > > > > I'm trying to configure a bootable image to be used in various situations > > and on various (mostly unknown) hardware. > > > > For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd > > also like to have it try to configure whatever interfaces the machine > > happens to have via DHCP. > > > > Other than specifying ifconfig_0="DHCP" once for every possible value of > > , is there a mechanism to do this already? > > ifconfig_DEFAULT Superb, thank you! > If you have non-Ethernet-like interfaces compiled in, you will probably > want create empty "ifconfig_" variables for them since DHCP won't > work very well there. :) Good point, thanks again :) Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpwXDII5LVgC.pgp Description: PGP signature
Using any network interface whatsoever
I'm trying to configure a bootable image to be used in various situations and on various (mostly unknown) hardware. For the filesystem I can use geom_label and /dev/ufs/UnlikelyString, but I'd also like to have it try to configure whatever interfaces the machine happens to have via DHCP. Other than specifying ifconfig_0="DHCP" once for every possible value of , is there a mechanism to do this already? Ceri -- That must be wonderful! I don't understand it at all. -- Moliere ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bafug Freebsd 6.1 meeting
On 4/4/06 02:04, "Julian Elischer" <[EMAIL PROTECTED]> wrote: > Julian Elischer wrote: > >> The topic is "6.1... your questions answered" >> >> Is there any call for it to be streamed out? > > > I ask because we usually stream the meetings when there is a speaker, > but this is more round table.. If it's not too much of a pain, I'd like to see it please, if only to see what kind of questions are out there. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exposing a file's creation time via find(1)
On Fri, Mar 24, 2006 at 10:40:58AM -0500, John Baldwin wrote:
> On Friday 24 March 2006 08:55, Ceri Davies wrote:
> > On Fri, Mar 24, 2006 at 12:06:18PM +0000, Ceri Davies wrote:
> > >
> > > While perusing my Daemon book I noticed that it mentioned the existence
> > > of the st_birthtime field in struct stat. I then also noticed that not
> > > many utilities expose this: the Daemon mentions dump(8), restore(8) and
> > > the only other one I could find was stat(1).
> > >
> > > The attached patch adds st_birthtime related primaries to find(1), being
> > > -Bmin, -Btime, -Bnewer et al. These let you use an inode's real
> > > creation time in find primitives. I have chosen 'B' over 'b' to match
> > > the format specifier from stat(1). It seems to do the right thing on UFS
> > > 1, 2 and MSDOS file systems, but some more testing would be appreciated.
> >
> > Note that there is a line out of place in the manpage diff - this is
> > corrected in a later version of the patch at
> > http://people.FreeBSD.org/~ceri/find-Btime.diff
>
> Could you add a new flag to ls to use birthtime for -t while you are at
> it? Good luck finding a flag to use though. :-P
That's the exact reason I didn't do it this round :)
Andrzej Tobola sent me this patch for ls -U pretty much immediately.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
# Dodanie do ls opcji -U - sortowanie po czasie kreacji
# Provide option -U - sort by time of file/directory creation
--- /usr/src/bin/ls/cmp.c-OLD Fri Jun 3 16:12:35 2005
+++ /usr/src/bin/ls/cmp.c Thu Jul 7 03:56:55 2005
@@ -115,6 +115,32 @@
}
int
+birthcmp(const FTSENT *a, const FTSENT *b)
+{
+
+ if (b->fts_statp->st_birthtimespec.tv_sec >
+ a->fts_statp->st_birthtimespec.tv_sec)
+ return (1);
+ if (b->fts_statp->st_birthtimespec.tv_sec <
+ a->fts_statp->st_birthtimespec.tv_sec)
+ return (-1);
+ if (b->fts_statp->st_birthtimespec.tv_nsec >
+ a->fts_statp->st_birthtimespec.tv_nsec)
+ return (1);
+ if (b->fts_statp->st_birthtimespec.tv_nsec <
+ a->fts_statp->st_birthtimespec.tv_nsec)
+ return (-1);
+ return (strcoll(a->fts_name, b->fts_name));
+}
+
+int
+revbirthcmp(const FTSENT *a, const FTSENT *b)
+{
+
+ return (birthcmp(b, a));
+}
+
+int
statcmp(const FTSENT *a, const FTSENT *b)
{
--- /usr/src/bin/ls/extern.h-OLDFri Jun 3 16:12:35 2005
+++ /usr/src/bin/ls/extern.hThu Jul 7 03:51:38 2005
@@ -32,6 +32,8 @@
int acccmp(const FTSENT *, const FTSENT *);
int revacccmp(const FTSENT *, const FTSENT *);
+int birthcmp(const FTSENT *, const FTSENT *);
+int revbirthcmp(const FTSENT *, const FTSENT *);
int modcmp(const FTSENT *, const FTSENT *);
int revmodcmp(const FTSENT *, const FTSENT *);
int namecmp(const FTSENT *, const FTSENT *);
--- /usr/src/bin/ls/ls.1-OLDFri Jun 3 16:12:35 2005
+++ /usr/src/bin/ls/ls.1Thu Jul 7 04:03:27 2005
@@ -143,6 +143,8 @@
.Dq ell )
option, display complete time information for the file, including
month, day, hour, minute, second, and year.
+.It Fl U
+Use time when file was created for sorting or printing.
.It Fl W
Display whiteouts when scanning directories.
.It Fl Z
--- /usr/src/bin/ls/ls.c.orig Thu Nov 10 05:44:07 2005
+++ /usr/src/bin/ls/ls.cThu Nov 10 15:15:31 2005
@@ -104,6 +104,7 @@
/* flags */
int f_accesstime; /* use time of last access */
+ int f_birthtime;/* use time of birth */
int f_flags;/* show flags associated with a file */
int f_humanval; /* show human-readable file sizes */
int f_inode;/* print inode */
@@ -179,7 +180,7 @@
fts_options = FTS_PHYSICAL;
while ((ch = getopt(argc, argv,
- "1ABCFGHILPRSTWZabcdfghiklmnopqrstuwx")) != -1) {
+ "1ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx")) != -1) {
switch (ch) {
/*
* The -1, -C, -x and -l options all override each other so
@@ -208,14 +209,21 @@
f_longform = 0;
f_singlecol = 0;
break;
- /* The -c and -u options override each other. */
+ /* The -c -u and -U options override each other. */
case 'c':
f_statustime = 1;
f_accesstime = 0;
+ f_birthtime = 0;
break;
case 'u':
f_accesstime = 1;
Re: Exposing a file's creation time via find(1)
On Fri, Mar 24, 2006 at 12:06:18PM +, Ceri Davies wrote: > > While perusing my Daemon book I noticed that it mentioned the existence > of the st_birthtime field in struct stat. I then also noticed that not > many utilities expose this: the Daemon mentions dump(8), restore(8) and > the only other one I could find was stat(1). > > The attached patch adds st_birthtime related primaries to find(1), being > -Bmin, -Btime, -Bnewer et al. These let you use an inode's real > creation time in find primitives. I have chosen 'B' over 'b' to match > the format specifier from stat(1). It seems to do the right thing on UFS > 1, 2 and MSDOS file systems, but some more testing would be appreciated. Note that there is a line out of place in the manpage diff - this is corrected in a later version of the patch at http://people.FreeBSD.org/~ceri/find-Btime.diff Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgpO9ttWPUjTV.pgp Description: PGP signature
Exposing a file's creation time via find(1)
While perusing my Daemon book I noticed that it mentioned the existence
of the st_birthtime field in struct stat. I then also noticed that not
many utilities expose this: the Daemon mentions dump(8), restore(8) and
the only other one I could find was stat(1).
The attached patch adds st_birthtime related primaries to find(1), being
-Bmin, -Btime, -Bnewer et al. These let you use an inode's real
creation time in find primitives. I have chosen 'B' over 'b' to match
the format specifier from stat(1). It seems to do the right thing on UFS
1, 2 and MSDOS file systems, but some more testing would be appreciated.
Cheers,
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
Index: find.1
===
RCS file: /home/ncvs/src/usr.bin/find/find.1,v
retrieving revision 1.73
diff -u -r1.73 find.1
--- find.1 14 Jun 2005 11:50:51 - 1.73
+++ find.1 24 Mar 2006 12:02:04 -
@@ -174,6 +174,34 @@
.El
.Sh PRIMARIES
.Bl -tag -width indent
+.It Ic -Bmin Ar n
+True if the difference between the time of a file's inode creation
+and the time
+.Nm
+was started, rounded up to the next full minute, is
+.Ar n
+minutes.
+.It Ic -Bnewer Ar file
+Same as
+.Ic -newerBm .
+.It Ic -Btime Ar n Ns Op Cm smhdw
+If no units are specified, this primary evaluates to
+true if the difference between the time of a file's inode creation
+and the time
+.Nm
+was started, rounded up to the next full 24-hour period, is
+.Ar n
+24-hour periods.
+.Pp
+If units are specified, this primary evaluates to
+true if the difference between the time of last change of file status
+information and the time
+.Nm
+was started is exactly
+.Ar n
+units.
+Please refer to the
+.Ic -atime
.It Ic -acl
May be used in conjunction with other options to locate
files with extended ACLs.
@@ -227,6 +255,7 @@
or
.Cm -
modifier.
+primary description for information on supported time units.
.It Ic -cmin Ar n
True if the difference between the time of last change of file status
information and the time
@@ -497,12 +526,16 @@
.It Ic -newer Ns Ar X Ns Ar Y Ar file
True if the current file has a more recent last access time
.Ar ( X Ns = Ns Cm a ) ,
+inode creation time
+.Ar ( X Ns = Ns Cm B ) ,
change time
.Ar ( X Ns = Ns Cm c ) ,
or modification time
.Ar ( X Ns = Ns Cm m )
than the last access time
.Ar ( Y Ns = Ns Cm a ) ,
+inode creation time
+.Ar ( Y Ns = Ns Cm B ) ,
change time
.Ar ( Y Ns = Ns Cm c ) ,
or modification time
Index: find.h
===
RCS file: /home/ncvs/src/usr.bin/find/find.h,v
retrieving revision 1.17
diff -u -r1.17 find.h
--- find.h 28 May 2004 17:17:15 - 1.17
+++ find.h 24 Mar 2006 12:02:04 -
@@ -72,6 +72,8 @@
#defineF_IGNCASE 0x0001 /* iname ipath iregex */
#defineF_EXACTTIME F_IGNCASE /* -[acm]time units syntax */
#define F_EXECPLUS 0x0002 /* -exec ... {} + */
+#defineF_TIME_B0x0004 /* one of -Btime, -Bnewer,
-newerB* */
+#defineF_TIME2_B 0x0008 /* one of -newer?B */
/* node definition */
typedef struct _plandata {
Index: function.c
===
RCS file: /home/ncvs/src/usr.bin/find/function.c,v
retrieving revision 1.54
diff -u -r1.54 function.c
--- function.c 25 Aug 2005 13:44:02 - 1.54
+++ function.c 24 Mar 2006 12:02:05 -
@@ -234,10 +234,10 @@
} /* nextarg() */
/*
- * The value of n for the inode times (atime, ctime, and mtime) is a range,
- * i.e. n matches from (n - 1) to n 24 hour periods. This interacts with
- * -n, such that "-mtime -1" would be less than 0 days, which isn't what the
- * user wanted. Correct so that -1 is "less than 1".
+ * The value of n for the inode times (atime, birthtime, ctime, mtime) is a
+ * range, i.e. n matches from (n - 1) to n 24 hour periods. This interacts
+ * with -n, such that "-mtime -1" would be less than 0 days, which isn't what
+ * the user wanted. Correct so that -1 is "less than 1".
*/
#defineTIME_CORRECT(p) \
if (((p)->flags & F_ELG_MASK) == F_LESSTHAN) \
@@ -248,6 +248,7 @@
*
*True if the difference between the
* file access time (-amin)
+ * file birth time (-Bmin)
* last change of file status information (-cmin)
* file modification time (-mmin)
*and the current time is n min periods.
@@ -261,6 +262,9 @@
} else if (plan->flags & F_TIME_A) {
COMPARE((now - entry->fts_statp->st_atime +
60 - 1) / 60, plan->t_data);
+ } else if (plan->flags & F_TIME_B) {
+ COMPARE((now - entry->fts_statp->st_birthtime +
+ 60 - 1) / 60, plan->t_data);
} else {
COMPARE((now - entry->fts_statp->st_mtime +
Re: Using pkg_add fetch only
On Sat, Jan 07, 2006 at 01:13:12AM +0100, Dirk Engling wrote: > > On Fri, 6 Jan 2006, Ceri Davies wrote: > > >I don't see your point. I thought you just wanted to download the > >packages and dependencies. > > Yes. pkg_add on the other hand leaves me with loads of _installed_ > packages but without the package tars from the server. Two stage process. In chroot(), pkg_add -r portupgrade, then pkg_fetch -R the stuff you want. Once you're done you can just blow away the chroot environment and all the installed stuff. Sure, it'll install a bunch of other crap like ruby, but it's a lot easier than hacking up your own tool. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpoZtNLurmoo.pgp Description: PGP signature
Re: Using pkg_add fetch only
On 6 Jan 2006, at 23:30, Dirk Engling wrote: On Fri, 6 Jan 2006, Ceri Davies wrote: The package cluster uses chroot() for this. Sure, but some post install scripts better run inside the running jail, those script will do stuff like creating users and installing files with user ids that are not even there in the host system. I don't see your point. I thought you just wanted to download the packages and dependencies. Ceri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using pkg_add fetch only
On 6 Jan 2006, at 20:59, Dirk Engling wrote: On Fri, 6 Jan 2006, Matt Emmerton wrote: What about pkg_fetch -R? This command is not in the base system. Since there is some logic in pkg_add for resolving dependencies and fetching packages I hoped, there might be some easy way not involving additional dependencies. The package cluster uses chroot() for this. Ceri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setfacl file modification time
On 5 Jan 2006, at 18:43, Ahnjoan Amous wrote: In 5.2.1-RELEASE, setfacl updates the modification time of the file when acls are changed. I haven't been able to find any complaints about this behavior, is this something folks on the list would expect when using setfacl? If so, does anyone know a work around? PR 76818 is open for this issue, but there is no progress logged at present. Ceri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My wish list for 6.1
On 21 Dec 2005, at 16:01, Juhana Tahvanainen wrote: how about: FreeBSD-Handbook-General (guaranteed to work with all FreeBSD systems, doesn't include stuff in FreeBSD-Handbook-BRANCH.x) FreeBSD-Handbook-4.x (guaranteed to work with 4.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-5.x (guaranteed to work with 5.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-6.x (guaranteed to work with 6.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-General is basically what we have now, and it sucks to maintain. Seriously though, all the interested people are on doc@; this discussion should be moved there. Ceri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mostly static binaries with crunchgen
On Fri, Dec 23, 2005 at 08:56:44AM -0500, John Baldwin wrote: > On Friday 23 December 2005 05:43 am, Ceri Davies wrote: > > On Wed, Dec 21, 2005 at 11:18:26AM -0500, John Baldwin wrote: > > > Sounds good (you could just go back to using -static in that case, but > > > that's a minor detail). Still have TORTUOUS change in your diff. :) > > > > No harm done :) > > > > New version fixing both issues at > > http://people.FreeBSD.org/~ceri/crunchgen.so.diff > > > > Ceri > > Commit! :) OK, done. Thanks for the help. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpq9I6amTPfa.pgp Description: PGP signature
Re: Mostly static binaries with crunchgen
On Wed, Dec 21, 2005 at 11:18:26AM -0500, John Baldwin wrote: > Sounds good (you could just go back to using -static in that case, but that's > a minor detail). Still have TORTUOUS change in your diff. :) No harm done :) New version fixing both issues at http://people.FreeBSD.org/~ceri/crunchgen.so.diff Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpDL6j9vPlKZ.pgp Description: PGP signature
Re: Mostly static binaries with crunchgen
On Tue, Dec 20, 2005 at 04:41:01PM -0500, John Baldwin wrote: > On Tuesday 20 December 2005 04:31 pm, Ceri Davies wrote: > > On Tue, Dec 20, 2005 at 01:43:58PM -0500, John Baldwin wrote: > > > On Tuesday 20 December 2005 10:58 am, Ceri Davies wrote: > > > > On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: > > > > > The other concern is does this force the entire crunch to require a > > > > > working rtld now? If so, that would mean that this wouldn't be > > > > > appropriate for something such as /rescue. If there were a way to > > > > > statically link rtld into the crunch itself that would probably be > > > > > ideal, but I'm not sure that is possible. > > > > > > > > No, just the dynamic bits require rtld. > > > > > > So you can still run /foo without rtld being present if foo doesn't need > > > dlopen, etc.? It looks like you link the crunch with -o dynamic, so > > > isn't the kernel going to complain when you try to exec it that it can't > > > find rtld if rtld is missing? (Think about /rescue if your rtld is hosed > > > and/or missing.) > > > > Sorry, you're correct of course. It's still useful in Adrian's > > environment at least (because he puts rtld on an MFS). > > One workaround for this case would be to have two crunches, one for the > pure-static stuff and one for the dynamic-using stuff. Alternatively, if you > had a way to statically link the rtld functions into the crunch you could > still use just one crunch. I just want to make sure we don't go turning this > on for /rescue since that needs to work if rtld is hosed (unless we go the > route of two crunches). Ah, OK. The new version attached ensures that if you don't use the libs_so declaration, you get an identical binary to that produced without the patch. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) ? crunchgen/fixit.conf Index: crunchgen/crunchgen.1 === RCS file: /home/ncvs/src/usr.sbin/crunch/crunchgen/crunchgen.1,v retrieving revision 1.28 diff -u -r1.28 crunchgen.1 --- crunchgen/crunchgen.1 30 May 2002 07:51:22 - 1.28 +++ crunchgen/crunchgen.1 21 Dec 2005 09:39:33 - @@ -16,7 +16,7 @@ .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL U.M. .\" BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN -.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTUOUS ACTION, ARISING OUT OF OR .\" IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" .\" Author: James da Silva, Systems Design and Analysis Group @@ -139,7 +139,7 @@ .Nm . This is useful to define some make variables such as .Va RELEASE_CRUNCH -or similar, which might affect the behaviour of +or similar, which might affect the behavior of .Xr make 1 and are annoying to pass through environment variables. .It Fl m Ar makefile-name @@ -210,6 +210,21 @@ Multiple .Ic libs lines can be specified. +.It Ic libs_so Ar libspec ... +A list of library specifications to be dynamically linked in the +crunched binary. +These libraries will need to be made available via the run-time link-editor +.Xr rtld 1 +when the component program that requires them is executed from +the crunched binary. +Multiple +.Ic libs_so +lines can be specified. +The +.Ic libs_so +directive overrides a library specified gratuitously on a +.Ic libs +line. .It Ic buildopts Ar buildopts ... A list of build options to be added to every make target. .It Ic ln Ar progname linkname @@ -417,9 +432,15 @@ .Dq Pa kcopy can be copied onto an install floppy and hard-linked to the names of the component programs. +.Pp +Note that if the +.Ic libs_so +command had been used, copies of the libraries so named +would also need to be copied to the install floppy. .Sh SEE ALSO .Xr crunchide 1 , -.Xr make 1 +.Xr make 1 , +.Xr rtld 1 .Sh CAVEATS While .Nm @@ -446,3 +467,10 @@ .Pp Copyright (c) 1994 University of Maryland. All Rights Reserved. +.Pp +The +.Ic libs_so +keyword was added in 2005 by +.An Adrian Steinmann Aq [EMAIL PROTECTED] +and +.An Ceri Davies Aq [EMAIL PROTECTED] . Index: crunchgen/crunchgen.c === RCS file: /home/ncvs/src/usr.sbin/crunch/crunchgen/crunchgen.c,v retrieving revision 1.35 diff -u -r1.35 crunchgen.c --- crunchgen/crunchgen.c 20 Jan 2005 10:49:03 - 1.35 +++ crunchgen/crunchge
Re: Mostly static binaries with crunchgen
On Tue, Dec 20, 2005 at 01:43:58PM -0500, John Baldwin wrote: > On Tuesday 20 December 2005 10:58 am, Ceri Davies wrote: > > On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: > > > The other concern is does this force the entire crunch to require a > > > working rtld now? If so, that would mean that this wouldn't be > > > appropriate for something such as /rescue. If there were a way to > > > statically link rtld into the crunch itself that would probably be ideal, > > > but I'm not sure that is possible. > > > > No, just the dynamic bits require rtld. > > So you can still run /foo without rtld being present if foo doesn't need > dlopen, etc.? It looks like you link the crunch with -o dynamic, so isn't > the kernel going to complain when you try to exec it that it can't find rtld > if rtld is missing? (Think about /rescue if your rtld is hosed and/or > missing.) Sorry, you're correct of course. It's still useful in Adrian's environment at least (because he puts rtld on an MFS). Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpru3o6Qts6M.pgp Description: PGP signature
Re: My wish list for 6.1
On Tue, Dec 20, 2005 at 03:46:53PM +0100, Joel Dahl wrote: > On Tue, 2005-12-20 at 14:22 +0000, Ceri Davies wrote: > > This is exactly the idea that I have been pimping to anyone who will > > listen for the last three months or so. I also think that it is > > advantageous for users who are using, say 4.2, to be able to find > > documentation for 4.2 without having to interpret a nest of "if you have > > 4.x do this, if 5.0 through 5.3 do that, else do the other". I don't > > think it's a lot of work to just branch the handbook (and FAQ > > if we decide to keep it) - in fact, for me, it would be a definite win - > > at release time, but it just doesn't seem to be what other people want > > done. > > Yep, I really like this. The current mess is impossible to maintain > (and also impossible to read). Yesterday I tried to update the kernel > configuration chapter to cover 6.0, but I gave up since there are "do > this for 4.X, do that for 5.X, and maybe this too for 6.X" everywhere. Yes, that's my major concern. I find working on the current documents too difficult. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpOKAMKs1nL1.pgp Description: PGP signature
Re: Mostly static binaries with crunchgen
On Tue, Dec 20, 2005 at 10:29:27AM -0500, John Baldwin wrote: > On Tuesday 20 December 2005 06:41 am, Ceri Davies wrote: > > Adrian Steinmann's talk at EuroBSDcon regarding a single user SSH daemon > > for rescue purposes highlighted an interesting point regarding some > > binaries. The GEOM userland binaries such as gmirror, gstripe, etc. use > > dlopen() to load classes from /lib/geom and therefore cannot be > > statically linked and, by extension, cannot be crunched with crunchgen. > > > > Adrian mentioned that it would be useful if crunchgen(1) supported > > "mostly static" binaries; i.e., a libs_so extension to crunchgen which > > would allow these binaries to be crunched, simply requiring then that > > rtld and the libraries be made available on the memory disk. This > > allows those of us who use GEOM classes to make a small rescue disk. > > > > I started to add this to crunchgen on the way home, and have worked with > > Adrian to finish it off. The patch is attached. It simply adds a > > "libs_so" keyword which specifies libraries that will be linked > > statically; all current config files continue to produce the same code > > as they did before. > > > > I'd like to commit this with a 6 week MFC period or so, but my mentor is > > currently busy. Could someone else please take this up? > > I don't think you should change TORTIOUS to TORTUOUS in the license. Reading > license disclaimers may indeed be tortuous, but tortious is an actual legal > term, not a misspelling. It comes from the root word 'tort' which is a legal > word for 'sue' (basically). Ah, I had parsed that as a whitespace change. Will revert :) > The other concern is does this force the entire crunch to require a working > rtld now? If so, that would mean that this wouldn't be appropriate for > something such as /rescue. If there were a way to statically link rtld into > the crunch itself that would probably be ideal, but I'm not sure that is > possible. No, just the dynamic bits require rtld. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpsccv4pS7IO.pgp Description: PGP signature
Re: My wish list for 6.1
On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote: > > > 3. Full review and update of the install docs, handbook, FAQ, etc. > > There are sections that are embarrassingly out of date (one section of > > the handbook apparently states that we only support a single brand of > > wifi cards). A co-worker of mine tried to install 6.0 using just the > > handbook install guide, and discovered that it really doesn't match > > reality anymore, in both big and small ways. Contact me directly if > > you would like his list of comments. > > I am wondering if it wouldn't be advantageous to have "versioned" > documents that just cover one specific release and not to cover all > realeases in single documents. > > I could imagine that it is harder to cover everything in single > documents than to perhaps copy the existing documentation when a new > branch is created and edit it to match just the new release. > > Maybe, I do not realize how much more work this would be but it would > probably enforce regular reviews of the documentation and the readers > would benefit from it. This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of "if you have 4.x do this, if 5.0 through 5.3 do that, else do the other". I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. I would encourage those interested to ask about it on [EMAIL PROTECTED] Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpxdR4OjEBSb.pgp Description: PGP signature
Re: My wish list for 6.1
On Sat, Dec 17, 2005 at 05:37:20AM -0500, Allen wrote: > On Saturday 17 December 2005 03:55, Christian Brueffer wrote: > > On Sat, Dec 17, 2005 at 08:55:00AM +, Allen wrote: > > > I know about the port tool, but what I'd love to have is a tool you > > > could run from the CLI or the GUI that would check for updates, and > > > then ask which ones to install, similar to Swaret on Slackware. This > > > way people can do the usual updates if they want, and people like me > > > can show people BSD and how great it is. > > > > You probably haven't seen ports/security/freebsd-update yet. > > Actually, I've seen that and it does come close... But it didn't seem to like > updating the Kernel or anything similar to the base system in the time I > spent with it. Look harder; those are the *only* things it will update. This is not portupgrade. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpjw89aCk0dx.pgp Description: PGP signature
Mostly static binaries with crunchgen
Adrian Steinmann's talk at EuroBSDcon regarding a single user SSH daemon for rescue purposes highlighted an interesting point regarding some binaries. The GEOM userland binaries such as gmirror, gstripe, etc. use dlopen() to load classes from /lib/geom and therefore cannot be statically linked and, by extension, cannot be crunched with crunchgen. Adrian mentioned that it would be useful if crunchgen(1) supported "mostly static" binaries; i.e., a libs_so extension to crunchgen which would allow these binaries to be crunched, simply requiring then that rtld and the libraries be made available on the memory disk. This allows those of us who use GEOM classes to make a small rescue disk. I started to add this to crunchgen on the way home, and have worked with Adrian to finish it off. The patch is attached. It simply adds a "libs_so" keyword which specifies libraries that will be linked statically; all current config files continue to produce the same code as they did before. I'd like to commit this with a 6 week MFC period or so, but my mentor is currently busy. Could someone else please take this up? Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) Index: crunchgen.1 === RCS file: /home/ncvs/src/usr.sbin/crunch/crunchgen/crunchgen.1,v retrieving revision 1.28 diff -u -r1.28 crunchgen.1 --- crunchgen.1 30 May 2002 07:51:22 - 1.28 +++ crunchgen.1 14 Dec 2005 21:11:30 - @@ -16,7 +16,7 @@ .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL U.M. .\" BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN -.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTUOUS ACTION, ARISING OUT OF OR .\" IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" .\" Author: James da Silva, Systems Design and Analysis Group @@ -139,7 +139,7 @@ .Nm . This is useful to define some make variables such as .Va RELEASE_CRUNCH -or similar, which might affect the behaviour of +or similar, which might affect the behavior of .Xr make 1 and are annoying to pass through environment variables. .It Fl m Ar makefile-name @@ -210,6 +210,21 @@ Multiple .Ic libs lines can be specified. +.It Ic libs_so Ar libspec ... +A list of library specifications to be dynamically linked in the +crunched binary. +These libraries will need to be made available via the run-time link-editor +.Xr rtld 1 +when the component program that requires them is executed from +the crunched binary. +Multiple +.Ic libs_so +lines can be specified. +The +.Ic libs_so +directive overrides a library specified gratuitously on a +.Ic libs +line. .It Ic buildopts Ar buildopts ... A list of build options to be added to every make target. .It Ic ln Ar progname linkname @@ -417,9 +432,15 @@ .Dq Pa kcopy can be copied onto an install floppy and hard-linked to the names of the component programs. +.Pp +Note that if the +.Ic libs_so +command had been used, copies of the libraries so named +would also need to be copied to the install floppy. .Sh SEE ALSO .Xr crunchide 1 , -.Xr make 1 +.Xr make 1 , +.Xr rtld 1 .Sh CAVEATS While .Nm @@ -446,3 +467,10 @@ .Pp Copyright (c) 1994 University of Maryland. All Rights Reserved. +.Pp +The +.Ic libs_so +keyword was added in 2005 by +.An Adrian Steinmann Aq [EMAIL PROTECTED] +and +.An Ceri Davies Aq [EMAIL PROTECTED] . Index: crunchgen.c === RCS file: /home/ncvs/src/usr.sbin/crunch/crunchgen/crunchgen.c,v retrieving revision 1.35 diff -u -r1.35 crunchgen.c --- crunchgen.c 20 Jan 2005 10:49:03 - 1.35 +++ crunchgen.c 14 Dec 2005 21:11:30 - @@ -74,6 +74,7 @@ strlst_t *keeplist; strlst_t *links; strlst_t *libs; + strlst_t *libs_so; int goterror; } prog_t; @@ -83,6 +84,7 @@ strlst_t *buildopts = NULL; strlst_t *srcdirs = NULL; strlst_t *libs = NULL; +strlst_t *libs_so = NULL; prog_t *progs = NULL; char confname[MAXPATHLEN], infilename[MAXPATHLEN]; @@ -106,6 +108,8 @@ void add_string(strlst_t **listp, char *str); int is_dir(char *pathname); int is_nonempty_file(char *pathname); +int subtract_strlst(strlst_t **lista, strlst_t **listb); +int in_list(strlst_t **listp, char *str); /* helper routines for main() */ @@ -238,6 +242,7 @@ void add_progs(int argc, char **argv); void add_link(int argc, char **argv); void add_libs(int argc, char **argv); +void add_libs_so(int argc, char **argv); void add_buildopts(int argc, char **argv); void add_special(int argc, char **argv); @@ -292,6 +297,8 @@
Re: nsswitch reviewer wanted
Hi Michael, On Thu, Nov 03, 2005 at 04:11:15PM +0300, Michael Bushkov wrote: > Ceri Davies wrote: > > >I realise that you weren't asking for comments, but I took a quick look > >at http://www.rsu.ru/~bushman/nsswitch_cached/nss_cached.patch and have > >some. I'll send this to the original lists too. > > Thanks for comments! I need them much. Glad to be of some help. Don't take anything I say as any kind of authority though. > >o There aren't nearly enough comments. Granted, I'm not a C aficionado, > > but it's ~ line 3200 of that patch before we come to a new non-trivial > > comment, and there aren't many after that. > > > Ok - I'll comment the code. Thanks. > >o cached/config.c has magic numbers in create_def_configuration_entry(), > > which probably belong as #defines in config.h instead. I'm not sure > > what style(9) says about that though, so am happy to be ignored. > > > Yes, that's right - I guess, the most correct way is to move them to > config.h As I mentioned, I'm no guru, but that seems to be conventional. > >o There is a single mention of a ssh_hostkeys cache in > > include/nsswitch.h, and no code to implement it. > > > I've implemented the patch for OpenSSH, which allows it to use nsswitch > for the hostkeys. It should be committed by the OpenSSH team. That's why > the ssh_hostkeys cache is mentioned in the nsswitch.h. This line can > easialy be removed - as it doesn't affect anything. I hadn't realised that. I'd be interested to see that patch if you still have a copy, as it would answer the question of how much work doing such a thing would be. So far as I'm concerned there is no issue leaving that in there, I just wanted to make sure that it hadn't slipped in by mistake. > >o On line 15448, there is a whitespace nit. Also, in this area, are we > > sure that there is no benefit in continuing to key by euid/egid if > > perform_actual_lookup is enabled; can we send the euid/egid with the > > lookup request? > > > You are talking about passing euid/egid to the underlying nsswitch > modules, right? This will require significant changes in these modules, > and, as far as I'm converned, won't gain us any benefits. > > I can't see any benefit of keying by euid/egud when the > 'perform_actual_lookups' mode is enabled. By ignoring them, we make the > cache common for all users, and no user can poison it - because all > requests are made solely by ourselves. If we won't ignore the euid/egid, > then for every user, we'll have to make similar requests, this will also > affect the cache size. > When perform_actual_lookups mode is off, cache should be certainly > separated by eud/egid for (basically) security reasons. OK, that's an good enough explanation for me. Thanks. > >o A user should be able to invalidate one of their caches (e.g., > > "cached -i hosts" to flush their hosts cache). Root should be able > > to do it for all users with a single command (e.g., "cached -I hosts" > > to flush all hosts caches). > > > Ok - I'll do that. Superb! > >o The manual for cached.conf is unclear over whether it's OK to name > > an "unknown" cache in cached.conf. > > > I'll corect this. In fact, it's ok to do that. I thought that was the intended meaning. That's great. > >o The location of cached.conf is defaulted to /usr/local/etc in > > cached/cached.c and should be changed on commit. > > > Will be corrected. Cool. Thanks again for working on this. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgp3lSS8cMNkQ.pgp Description: PGP signature
Re: nsswitch reviewer wanted
In the list that shall not be cc'd to, on Tue, Nov 01, 2005 at 04:15:07PM -0800, Brooks Davis wrote: > Michael Bushkov disk some interesting work for use under the Google > Summer of Code and I'd like to see the appropriate parts committed. > Unfortunately, this isn't an area I have great depths of knowledge so > I'm hoping someone one else is interested in working on this. I realise that you weren't asking for comments, but I took a quick look at http://www.rsu.ru/~bushman/nsswitch_cached/nss_cached.patch and have some. I'll send this to the original lists too. o There aren't nearly enough comments. Granted, I'm not a C aficionado, but it's ~ line 3200 of that patch before we come to a new non-trivial comment, and there aren't many after that. o cached/config.c has magic numbers in create_def_configuration_entry(), which probably belong as #defines in config.h instead. I'm not sure what style(9) says about that though, so am happy to be ignored. o There is a single mention of a ssh_hostkeys cache in include/nsswitch.h, and no code to implement it. o On line 15448, there is a whitespace nit. Also, in this area, are we sure that there is no benefit in continuing to key by euid/egid if perform_actual_lookup is enabled; can we send the euid/egid with the lookup request? o A user should be able to invalidate one of their caches (e.g., "cached -i hosts" to flush their hosts cache). Root should be able to do it for all users with a single command (e.g., "cached -I hosts" to flush all hosts caches). o The manual for cached.conf is unclear over whether it's OK to name an "unknown" cache in cached.conf. o The location of cached.conf is defaulted to /usr/local/etc in cached/cached.c and should be changed on commit. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpA74NuO4YoN.pgp Description: PGP signature
Re: Serious braindamage in the send-pr web interface
On Tue, Jun 21, 2005 at 03:52:02PM -0400, Martin Cracauer wrote: > The security code of the web interface seems to really screw people > over (the image displaying a text that you have to enter). > > It goes like this: > - open web page > - enter PR > - enter security code but get anything wrong (case is sufficient) > > You get an error complaing about the security code. > > Press back. Your carefully edited PR is still there. Good. > > However, it displays the same image and the same security code as > before, although send-pr seems to have generated a new one internally. > The new code is not displayed, however, since there is no expire > header on the old one and you just hit the "back" button. > > So it displays the old code to the user while it already expects a new > one. > > So it rejects everything that comes out of the sequence "back button" > and resubmitting, so matter how often you do it. It never displays > its currently expected code in an image in the user's browser, it > reuses the first image every time. > > If you figure that this is the problem you press reload - and your PR > is gone :-/ > > I think this might be fixable as easy as setting an expire header on > the image. It has Pragma: no-cache and a dummy '?' in the URL. What does an "expire header" that expires immediatelylook like? > Also, it shouldn't be all-uppercase and case sensitive, that is > pointless. Point taken; I actually remember committing lowercase letters. Interesting that it never really happened... Ceri PS www issues go to www@, not [EMAIL PROTECTED] -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgp60wJhcDwRM.pgp Description: PGP signature
Re: How many developers?
On Thu, Feb 10, 2005 at 03:42:51PM +0100, Wilko Bulte wrote: > On Thu, Feb 10, 2005 at 02:53:11PM +0100, Ivan Voras wrote.. > > For statistical purposes, where can I get information such as the number > > of developers (with commit bit?) active on the FreeBSD project? > > I don't think there is a published (or unpublished for that matter) > statistic like that available. > > You could run a wc -l on the various access files, but that does not > tell you who is active and who isnt. Peter's cutoff files are updated daily for that: http://people.freebsd.org/~peter/*cutoff* Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpT7keVf80RO.pgp Description: PGP signature
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
On Fri, Jan 07, 2005 at 06:10:06PM +0800, Xin LI wrote: > On Fri, Jan 07, 2005 at 09:21:10AM +0000, Ceri Davies wrote: > > I don't really think that this benchmark is bad news for either OS. My > > only real concern are the process creation/termination results on FreeBSD. > > I guess that this might worth investigating: > > http://people.freebsd.org/~das/pbench/pbench.html > > (Unfortuantelly, neither tjr@ nor I have touched our patchsets recently. > A most recent snapshot of the two patchsets are here: > > http://research.delphij.net/freebsd/pid.diff > http://research.delphij.net/freebsd/pid-tjr.diff) > > Most of the work was to catch up with Aug 2004's -CURRENT, but it might > be easier to bring them up-to-date instead of working from the very original > patches =-) Looks great. Any reason why neither has been committed? Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgp19cu4wd0Hs.pgp Description: PGP signature
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
On Fri, Jan 07, 2005 at 01:10:04AM -0800, Kamal R. Prasad wrote: > > > Hi Robert, > > > > the benchmark you cited is for uniprocessor systems > > only. > > It says nothing about multiprocessor performance, > > which is what FreeBSD > > is aiming for. > Doesn't the (ULE) scheduler have a switch to ensure > that performance is optimal on a uniprocessor machine > too? I don't know, but if it did that would only affect scheduling, and only in the ULE case at that. ULE was broken in 5.3-RELEASE. I don't really think that this benchmark is bad news for either OS. My only real concern are the process creation/termination results on FreeBSD. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpfk1wiMTbRi.pgp Description: PGP signature
Re: Oracle 9/10g under FreeBSD
On Wed, Dec 01, 2004 at 08:19:02AM +0100, Christoph Kukulies wrote: > Anyone having one of the Oracle linux dists running under FreeBSD? I have 9i running. It turned out to be easier doing it that way than finding a Linux dist that would work. I followed the instructions at http://ezine.daemonnews.org/200402/oracle.html, which actually worked. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpxh04Qhs3pp.pgp Description: PGP signature
Re: tcsh is not csh
On Mon, Nov 15, 2004 at 05:09:06PM -0600, Kevin Lyons wrote: > you missed the rest of the thread. /bin/csh is not /bin/tcsh. i have > run into a fairly important compatibility problem brought on by this. later. As you've been told, calling tcsh as csh should activate csh compatibility mode. If this is buggy then you should report it to the tcsh author, which is the same for all contributed software in the base. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpIy4NbVh07e.pgp Description: PGP signature
Re: tcsh is not csh
On Fri, Nov 12, 2004 at 06:59:32PM +0200, Peter Pentchev wrote: > On Thu, Nov 11, 2004 at 04:00:25PM -0600, Kevin Lyons wrote: > Thus, if there is a bug in tcsh's csh compatibility mode, you really > might do better to report it to the tcsh maintainers - on the several > occassions when I've needed to report tcsh(1) and file(1) issues to > Christos Zoulas, I've found him to be quite responsive and willing to > accomodate reasonable requests and bugfixes :) The implication being that you refrain from calling him pathetic when you report the bug. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgprP9OQcx9zq.pgp Description: PGP signature
Re: Protection from the dreaded "rm -fr /"
On Mon, Oct 04, 2004 at 08:27:45PM +1000, Dave Horsfall wrote: > On Mon, 4 Oct 2004, Dmitry Karasik wrote: > > > I just wonder, if 'rm' is so fearful to you, why bother changing rm(1)? > > Write a simple wrapper around, as many sysadmins do for their needs, and > > use it instead of rm. > > Precisely. > > This is -hackers; why do we need to be protected from ourselves? All the world is not -hackers. Ceri -- I hear thought presenting the problem. -- dadadodo -c 1 Mail/trhodes pgpIxzzXKO4D7.pgp Description: PGP signature
Re: Protection from the dreaded "rm -fr /"
On Sat, Oct 02, 2004 at 05:22:50PM -0400, Garance A Drosihn wrote: > At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: > >On 2004-10-02 21:23, Lee Harr <[EMAIL PROTECTED]> wrote: > > > > John Beck, who works for Sun, has posted an entry in his blog > > > > yesterday about "rm -fr /" protection, which I liked a lot: > > > > > > > > http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection > >> > > > > > His idea was remarkably simple, so I went ahead and wrote this > > > > patch for rm(1) of FreeBSD: > > > > >> How about: > >> > >> chflags sunlnk / > >> ? > > > >Setting sunlink on / will only protect the / directory, not its > >descendants, so you don't gain much. > > We could add a new flag "srunlnk", or maybe even "srm-r". The "rm" > command will always have to stat() the file it is given (just to > see if it is a directory), so it could check to see if this flag > is turned on. If it is turned on, then 'rm' could refuse to honor > any '-rf' request on that directory. I love the idea of this; it's the most elegant solution offered yet. I'm also looking forward to the forthcoming bikeshed regarding exactly what the flag should be called. ;-) Ceri -- It is not tinfoil, it is my new skin. I am a robot. pgpkZ5br1IWD6.pgp Description: PGP signature
Re: Protection from the dreaded "rm -fr /"
On Sat, Oct 02, 2004 at 11:51:43AM +0300, Giorgos Keramidas wrote: > Adding protection that prevents foot-shooting is not something without > precedent to FreeBSD either: > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/boot0cfg/boot0cfg.c.diff?r1=1.13&r2=1.14 Is that the correct reference? Ceri -- It is not tinfoil, it is my new skin. I am a robot. pgpl5oKaiPcHb.pgp Description: PGP signature
Re: Protection from the dreaded "rm -fr /"
On Sat, Oct 02, 2004 at 11:23:52AM +0200, Max Laier wrote: > [ Sorry to be so negative ... ] > > At very least you should consider to error out silently as POSIX requires "-f" > to be silent. Other than that you should really look into the standards and > what they way about rm and friends. Are you sure? From the RATIONALE section of http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html: "It is less clear that error messages regarding files that cannot be unlinked (removed) should be suppressed. Although this is historical practice, this volume of IEEE Std 1003.1-2001 does not permit the -f option to suppress such messages." > I am not a fan of providing seat belts like this. People concerned about this, > can "alias rm 'rm -i'" etc. etc. Others have commented like this ... > > If you still have to make this change, make it tuneable with a environment > variable (and make it default to off). I'd prefer that too. Ceri -- It is not tinfoil, it is my new skin. I am a robot. pgpFbCRBi9tq8.pgp Description: PGP signature
Re: Third IDE hard disk
On Sat, May 15, 2004 at 08:26:53PM +0200, Dag-Erling Sm?rgrav wrote: > Ceri Davies <[EMAIL PROTECTED]> writes: > > If the controller on these boards doesn't detect a drive attached, then > > the BIOS for the controller doesn't get installed, so make sure that > > it's probing the disks correctly when the machine boots, otherwise any > > OS will be unable to find it. > > Rubbish. FreeBSD does not need a working ATA BIOS to detect and use > an ATA controller. atacontrol agrees. Guess I'm not used to having a machine boot this fast and missed the entry on boot. Ceri -- pgpm8xKrVekKb.pgp Description: PGP signature
Re: Third IDE hard disk
On Fri, May 14, 2004 at 11:28:24PM +, Mark wrote: > Vladim?r Benc wrote: > > > If a BSD box doesn't "see" the third IDE, this seems to be in the > > BIOS is Enabled only Primary IDE Controller. You must enable both > > Channels on the controller. > > All three IDE controllers are enabled in the BIOS, as far as I can tell. If the controller on these boards doesn't detect a drive attached, then the BIOS for the controller doesn't get installed, so make sure that it's probing the disks correctly when the machine boots, otherwise any OS will be unable to find it. > My greatest fear, however, is that FreeBSD cannot deal with a third IDE > controller. Can you at least alleviate that fear? Definitely not the case. Ceri -- pgp0.pgp Description: PGP signature
Re: the new send-pr web interface
On Wed, Feb 11, 2004 at 01:14:46PM +0100, Friedemann Becker wrote: > hello, > > I sent a new bugreport via the web interface and noticed two things I > wondered about: > > - in the multiline forms it seems like there would be linebreaking > when typing in the report, but on the website it shows as one long line. > It's not very nice when you have to scroll around for every line longer > than your screen width. Hmm - I think that's a function of the browser more than anything else, but would be happy to receive confirmation either way (and a way to work round it if there is one). > - it seems to me that the bugreport isn't sent to freebsd-bugs > automatically, although it may be that it could show up in a day or two. > but since yesterday the bugreport is on the website, while freebsd-bugs > didn't get a message. sending a message is important IMHO, because too > many bugreports are unnoticed for a long time, even though there are > sent to the mailing list. That really depends on which category the PR you raised was in. If you're talking about 62671, then that's a ports PR and will have been sent to [EMAIL PROTECTED] instead. Ceri -- pgp0.pgp Description: PGP signature
Re: Yes, send-pr results in virus emails
On Wed, Jan 28, 2004 at 10:12:02AM -0800, Tim Kientzle wrote: > Leo Bicknell wrote: > >In a message written on Tue, Jan 27, 2004 at 01:47:57PM -0600, Brandon D. > >Valentine wrote: > > > >>I'm afraid there's not much that FreeBSD can do about this. All PRs are > >>forwarded to the public freebsd-bugs mailing list ... > > > >There's no reason the sender address needs to go to the mailing > >list or be visable on the web, is there? > > I have fixed a number of problems on my system > by looking through the PR database and contacting > folks who had similar problems in the past. > > Suppressing the email addresses of bug submitters > would largely eliminate this very useful support avenue. It also will not happen (at least while I am responsible for the PRs). Ceri -- pgp0.pgp Description: PGP signature
Re: A way to clean up PRs?
On Thu, Jan 08, 2004 at 10:51:53PM +, Paul Robinson wrote: > Just a thought: > > How about everything that hasn't been touched in 3 years gets put into a > special state of "closed-believed-dead", everything over 12 months (or > 6?) gets the same AFTER an e-mail has been sent out to the originator to > see if the problem still exists? > > It's just that way, I think a lot of PRs for obsolete hardware and > versions will get closed up, thereby making it easier for those of us > trying to pick our way through and see what is still new and relevant > and in need of some love and care and attention. If somebody still has > the problem and it's an issue, it just gets a new PR that comes back on > the top of the queue, it's live and we can deal with PRs as they come in. > > Thoughts? Just a thought that might help clean up the DB on an idle > Thursday evening. I'm sure it's been thought of before. Well, here's a extract from a mail I sent to another non-committer interested in doing the same thing, about two days ago. Note that we do already timeout PRs in feedback after a period of time without a reply (currently 3 months). Also note that there's a bugbusters@ list where this kind of discussion should live, but I think I may be the only person subscribed (although rousing the list is really my responsibility, I've yet to think up a good enough scheme). Forwarded mail: Thanks for the offer of help. Sending stuff to current could be considered useful, but committers interested in fixing bugs (which is hopefully all of them!) will all be subscribed to freebsd-bugs@, which means that by simply submitting a followup to the PR they'll get automatically notified. There a few ways for non-committers to help out though: if you think that a PR can be closed, then submit a followup to the PR with the reason why, and include the string "This PR can be closed". The reason can be anything from "this isn't a problem on later releases", "this was fixed in revision x of src/foo/bar/quux.c" to "the user is at fault". Just because a PR can't be closed though, if you have information to add to a PR (an updated patch, "cannot replicate here", etc.) then send it in as a followup. Of course, if you know of (or can code) a fix, send it! Ceri -- pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 04:36:47PM +, Ceri Davies wrote: > On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: > > All, > > > > Every FreeBSD release cycle in the past year has hit bumps due to install > > floppy problems. This is becoming more and more of a burden on the > > Release Engineering Team, as we simply do not have the resources to > > constantly battle the floppies. > > Floppies can go as far as I'm concerned, with the one proviso that we > start shipping a /boot.config containing '-P'. Without floppies, the > only ways to do a headless install are PXE and cutting your own release > with that /boot.config in place, and not all machines can do PXE. Actually, I'd like to go one further and suggest that we do this anyway. Ceri -- pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: > All, > > Every FreeBSD release cycle in the past year has hit bumps due to install > floppy problems. This is becoming more and more of a burden on the > Release Engineering Team, as we simply do not have the resources to > constantly battle the floppies. Floppies can go as far as I'm concerned, with the one proviso that we start shipping a /boot.config containing '-P'. Without floppies, the only ways to do a headless install are PXE and cutting your own release with that /boot.config in place, and not all machines can do PXE. Ceri -- pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Wed, Jan 07, 2004 at 09:45:25PM -0600, Ryan Sommers wrote: > On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: > > 1) Allow for paid development for a specific bug/feature > > > > - Setup some program that allows users like myself to pay for a > > developers time to fix a specific bug. The company I work for > > would easily pay serious dollars to fix our SMP problems with 4.X. > > Unfortunetly, getting someone's attention that has a great > > understanding of the OS is hard to find without rude remarks and > > what-not. > > > > You could even extend it as far as saying we will promote this PR > > to the top of the list of tasks if you pay us XX dollars. Or > > maybe, the more you pay the higher you go. > > > > This would reassure the user base that things CAN get done if > > needed and also let the developer/bug fixer feel like they can > > make money and have some fun. It will also bring in money for the > > project as part of that money could go back into the Project. > > > > You could easily setup a "pool" mailling list (like -requests) > > which someone like myself would email a request with the problem > > description (or PR). If a developer is interested in tackling the > > problem for money, we could privately negotiate a price. > > > > The same can be done for driver development and others. Make it a > > "Donation for a specific request". I don't want to give money to > > some Foundation where money can be thrown around in the wrong > > areas. I want to pay the developer personally for their efforts. > > ( I feel the same should be done with our taxes as well ;-) > > > > I really don't like the idea of making this a "policy," or even some > official part of the project. I think this might discourage some from > contributing in hopes to be paid for it. I think a better solution for > companies looking for this would be to post to the jobs@ mailing list > noting that it is a temp job. > > I don't think giving priority to paying entities is a path the project > should tread down. If someone needs FreeBSD developer work they should > look for someone to hire. Something like this might also jeopardize the > project's "not for profit" status. I think the jobs@ mailing list would > be a better start. Absolutely. At least in Britain, the Project could then be seen as working as an agent which has the potential to cause problems that we don't need and probably would find very hard to deal with. Ceri -- pgp0.pgp Description: PGP signature
Re: I'm resigning from FreeBSD
On Sat, Dec 27, 2003 at 12:12:03PM -0500, Lucas Holt wrote: > Funny, I see people switching to *BSD from Linux all the time. I've > "converted" quite a few people at Western Michigan where i'm a student. > > Most people think of FreeBSD as the "new" linux. You have to think to > use it, as opposed to the redhat idiot wizards. > > That guy who quit reminded me of Theo from the OpenBSD project for some > reason. I read the exchange between him and the NetBSD group when they > kicked him out. Maybe that guy will get pissed and do something cool > like Theo did. Nobody quit. Ceri -- pgp0.pgp Description: PGP signature
Re: "secure" file flag?
On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote: > I am wondering if it is useful to have a "secure" file flag?? > > The secure file flag will be set for files that contain sensitive data. > Then the OS will take special care when operating on those "secure" > files. > > e.g. when deleting a "secure" file, the OS will overwrite the file with > random data. It would also be useful to have a "noexport" flag, which would have the NFS code refuse to send it over the network. I could personally use this for setting on my PGP and SSH keys, while exporting the rest of /home. I did look at implementing this, but couldn't find the "correct" place to do the check for the flag. Any pointers for a kernel newbie? Ceri -- pgp0.pgp Description: PGP signature
Re: interrupt statistics
On Wed, Nov 19, 2003 at 09:46:02AM +0100, Dag-Erling Sm?rgrav wrote: > ISTR there is a tool (other than systat -vmstat) that shows interrupt > statistics for all interrupts, but I can't find anything except the > hw.intrnames and hw.intrcnt sysctls, which aren't directly human- > readable. Does anyone have any idea of what my deficient memory won't > tell me? Do you mean something other than vmstat -i? Ceri -- pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, Sep 16, 2003 at 10:23:56AM -1000, Clifton Royston wrote: > In the meantime I'm trying to figure out if there's some simple hack > to disregard these wildcard A records, short of requesting zone > transfers of the root nameservers (e.g. via peering with > f.root-servers.net) and purging those records out of the zone before > loading it. These records aren't in the root zone. Ceri -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com pgp0.pgp Description: PGP signature
Re: Hi!Dear FreeBSD!
On Sat, Feb 01, 2003 at 10:45:48AM -0800, Julian Elischer wrote: > maybe we should make some sort of geographical registration > web page so that people can find each other? ports/astro/xearth/files/freebsd.committers.markers ? Ceri -- The power of the heroic dwarves has come! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: > If you don't have the machine-power to run make release yourself, > I hope the japanese snapshot server is producing good snapshots, > if that fails, I would appreciate if somebody will produce and put up > good releases and/or ISO images somewhere. snapshots.jp.freebsd.org hasn't completed a make release since September 17th by the looks of things. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Another panic in -STABLE, yesterday's tree
On Sun, May 26, 2002 at 05:00:05PM +0100, Dominic Marks wrote: > On Sun, May 26, 2002 at 04:30:24PM +0100, Ceri Davies wrote: > > On Sun, May 26, 2002 at 01:48:12PM +0100, Dominic Marks wrote: > > > I had this problem. To get good backtraces I do the following. I don't > > > know how "good" this method is, but it works for me. > > > > > > After making your system with makeoptions="-g", add the following to > > > /etc/rc.conf: > > > > > > savecore_flags="-N /usr/obj/usr/src/sys/GALLIUM/kernel.debug" > > > > > > Using the correct path for your kernel name. Then, in your crash dump > > > directory (mine is /usr/crash) run gdb -k kernel.N vmcore.N and you > > > should be able to get a good backtrace with symbols. > > > > That backtrace is from a debug kernel though? > > In my kernel config I have : > > makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols > > > > and after running "make installkernel" I just > > cp /usr/obj/usr/src/sys/RHADAMANTH/kernel.debug /var/crash > > > > Is that really not good enough (if not, I'll do it like you've suggested, but > > I don't always keep /usr/obj around) ? > > Well, I should have been more clear. You don't need to keep it in > /usr/obj. The following should work just as well. > > # cp /usr/obj/..BLAH../kernel.debug /var/debugkernels/ > > Then modify the savecore flags appropriately. Trying to get it to work > after this point always failed for me. YMMV. OK, I'm with you - I'll set that up now and wait for the next panic. Thanks again, Ceri -- get the cool shoe shine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Another panic in -STABLE, yesterday's tree
On Sun, May 26, 2002 at 01:48:12PM +0100, Dominic Marks wrote: > On Sun, May 26, 2002 at 12:26:41PM +0100, Ceri Davies wrote: > > > > I've had another kernel panic, this time from a cold boot (the machine had > > been powered off overnight), with a new world and kernel built yesterday: > > > > FreeBSD rhadamanth.private.submonkey.net 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0: >Wed May 1 21:59:38 BST 2002 >[EMAIL PROTECTED]:/usr/obj/usr/src/sys/RHADAMANTH i386 > > > > I've attached a backtrace - further information is available if someone > > tells how to summon it from gdb (I won't delete vmcore this time...) > > I had this problem. To get good backtraces I do the following. I don't > know how "good" this method is, but it works for me. > > After making your system with makeoptions="-g", add the following to > /etc/rc.conf: > > savecore_flags="-N /usr/obj/usr/src/sys/GALLIUM/kernel.debug" > > Using the correct path for your kernel name. Then, in your crash dump > directory (mine is /usr/crash) run gdb -k kernel.N vmcore.N and you > should be able to get a good backtrace with symbols. That backtrace is from a debug kernel though? In my kernel config I have : makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols and after running "make installkernel" I just cp /usr/obj/usr/src/sys/RHADAMANTH/kernel.debug /var/crash Is that really not good enough (if not, I'll do it like you've suggested, but I don't always keep /usr/obj around) ? Thanks, Ceri -- get the cool shoe shine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Another panic in -STABLE, yesterday's tree
I've had another kernel panic, this time from a cold boot (the machine had
been powered off overnight), with a new world and kernel built yesterday:
FreeBSD rhadamanth.private.submonkey.net 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0: Wed
May 1 21:59:38 BST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/RHADAMANTH i386
I've attached a backtrace - further information is available if someone
tells how to summon it from gdb (I won't delete vmcore this time...)
Also attached is /var/run/dmesg.boot if it's of use.
Thanks,
Ceri
--
get the cool shoe shine
Script started on Sun May 26 12:24:21 2002
You have mail.
{[1m[4mroot[m@rhadamanth}-{/var/crash} # gdb -k kernel.debug vmcore.6
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 0 cpus
IdlePTD at phsyical address 0x
initial pcb at physical address 0x002d28e0
panic messages:
---
dmesg: kvm_read: invalid address (c02cbde0)
---
cannot read proc pointer at ff84
(kgdb) bt
#0 0x0 in ?? ()
(kgdb) q
{[1m[4mroot[m@rhadamanth}-{/var/crash} # exit
exit
Script done on Sun May 26 12:25:14 2002
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.6-PRERELEASE #0: Wed May 1 21:59:38 BST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/RHADAMANTH
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (863.68-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x383fbff
real memory = 536805376 (524224K bytes)
avail memory = 519118848 (506952K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0
cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc034f000.
Pentium Pro MTRR support enabled
Using $PIR table, 8 entries at 0xc00f7220
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
IOAPIC #0 intpin 19 -> irq 2
IOAPIC #0 intpin 18 -> irq 16
IOAPIC #0 intpin 16 -> irq 17
IOAPIC #0 intpin 17 -> irq 18
pci0: on pcib0
pcib1: at device 1.0 on pci0
pci1: on pcib1
pci1: at 0.0 irq 17
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: port 0xb800-0xb81f irq 2 at device 7.2 on pci0
usb0: on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ulpt0: Hewlett-Packard DeskJet 940C, rev 1.10/1.00, addr 2, iclass 7/1
uhci1: port 0xbc00-0xbc1f irq 2 at device 7.3 on pci0
usb1: on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pci0: (vendor=0x1106, dev=0x3057) at 7.4
atapci1: port
0xcc00-0xcc0f,0xd000-0xd003,0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07 mem
0xdfffc000-0xdfff irq 16 at device 10.0 on pci0
ata2: at 0xdc00 on atapci1
ata3: at 0xd400 on atapci1
pcm0: port 0xc000-0xc03f irq 2 at device 11.0 on pci0
ed0: port 0xc400-0xc41f irq 17 at device 12.0 on
pci0
ed0: address 00:40:95:44:3f:bc, type NE2000 (16 bit)
dc0: port 0xc800-0xc8ff mem 0xdfffbf00-0xdfffbfff
irq 18 at device 13.0 on pci0
dc0: Ethernet address: 00:50:bf:76:2a:98
miibus0: on dc0
dcphy0: on miibus0
dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
orm0: at iomem 0xc-0xcc7ff,0xcc800-0xc on isa0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
plip0: on ppbus0
lpt0: on ppbus0
lpt0: Interrupt-driven port
ppi0: on ppbus0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
IP packet filtering initialized, divert enabled, rule-based forwarding enabled,
default to deny, logging limited to 100 packets/entry by de
Re: Kernel panic on boot with 4.6-PRERELEASE
On Fri, May 24, 2002 at 05:59:26PM +0100, Ceri Davies wrote: > > Any further information can be provided if you give me instructions on how to > get it. Bugger, scratch that; I just deleted the vmcore (no, I have no idea why either). Aargh. Ceri -- get the cool shoe shine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel panic on boot with 4.6-PRERELEASE
Hi all,
Earlier today I suffered a kernel panic while the system was coming back up
from "shutdown -r now".
This is an SMP system running 4.6-PRERELEASE from May 1st. Here's uname -a :
FreeBSD rhadamanth.private.submonkey.net 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0: Wed
May 1 21:59:38 BST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/RHADAMANTH i386
Attached is the output from a script session of gdb; I tried following Michael
Lucas' hints from Big Scary Daemons, but it seems to have hit a bit of a dead
end.
Also attached is the output of dmesg.
Any further information can be provided if you give me instructions on how to
get it.
Thanks,
Ceri
--
get the cool shoe shine
Script started on Fri May 24 17:50:16 2002
{[1m[4mroot[m@rhadamanth}-{/var/crash} # gdb -k ker
kernel.5 kernel.debug*
{[1m[4mroot[m@rhadamanth}-{/var/crash} # gdb -k kernel.debug vmcore.5
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD at phsyical address 0x0036e000
initial pcb at physical address 0x002d1aa0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0103; cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0x0
stack pointer = 0x10:0xd5c0ed98
frame pointer = 0x10:0xd5c0eda0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 122 (mountd)
interrupt mask = bio <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0103; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks...
Fatal trap 12: page fault while in kernel mode
mp_lock = 0104; cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0x0
stack pointer = 0x10:0xd5c0eb0c
frame pointer = 0x10:0xd5c0eb3c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 122 (mountd)
interrupt mask = bio <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0104; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 9s
dumping to dev #ad/0x30021, offset 128
dump ata2: resetting devices .. done
511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491
490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470
469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449
448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428
427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407
406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386
385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365
364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344
343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323
322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302
301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281
280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260
259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239
238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218
217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197
196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176
175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155
154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134
133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113
112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89
88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60
59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31
30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487
