Re: world broken
On Thu, Aug 15, 2002 at 03:18:59PM -0700, Alfred Perlstein wrote: /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: useless keyword o r type name in empty declaration /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: empty declaration I get those a lot now... please fix. This happens because GCC 3 doesn't define __STDC_VERSION__ unless you specify -std=something, whereas 2.95 defines it to 199409L if no -std option is given. I'm not quite sure how to check for this. Perhaps this would work: #if __STDC_VERSION__ 199901L __GNUC__ 3 typedef int _Bool; #endif GCC 3 appears to declare _Bool regardless of any -std option. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
subscribe
Re: buildworld breakage
I ran into this also, and a bit of fiddling with a debugger was un-enlightening -- it was segfaulting on a write to __collate_substitute_table in parse.y. The pointer to the table didn't appear to be corrupted, and it should have been in writable memory. It also appeared to be properly aligned. I moved on to other stuff but was planning to submit a bug report if it persisted (and therefore wasn't a local nit of mine due to heavy local kernel mods). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 15 Aug 2002, Mike Makonnen wrote: I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 Stop in /daemon/build/current/src/share/colldef. *** Error code 1 Stop in /daemon/build/current/src/share. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
question about ipl.ko
i try to load ipl.ko #kldload -v /boot/kernel/ipl.ko kldload: can't load /boot/kernel/ipl.ko: Exec format error #kldstat Id Refs AddressSize Name 1 10 0xc010 45fd04 kernel 21 0xc056 1b410linux.ko 32 0xc057c000 90f0 ipfw.ko 41 0xc0586000 5374 ip6fw.ko 51 0xc058c000 e6d8 agp.ko 61 0xc059b000 77d8 dummynet.ko 71 0xc2d9a000 16000nfsserver.ko #dmesg FreeBSD 5.0-CURRENT #4: Wed Aug 14 13:46:59 CEST 2002 root@kripel:/usr/src/sys/i386/compile/angel Preloaded elf kernel /boot//kernel/kernel at 0xc05a4000. Preloaded elf module /boot//kernel/linux.ko at 0xc05a40ac. Preloaded elf module /boot//kernel/ipfw.ko at 0xc05a4158. Preloaded elf module /boot//kernel/ip6fw.ko at 0xc05a4204. Preloaded elf module /boot//kernel/agp.ko at 0xc05a42b0. Preloaded elf module /boot//kernel/dummynet.ko at 0xc05a435c. it's my problem, for example in the kernel module loading sequence, or current problem ? thank -- -- bye R.R.K.K. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
World breakage in lib/libc/gen/disklabel.c; here's a patch
stage 4: building libraries ... cc -O -pipe -DLIBC_MAJOR=5 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../. ./include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/S4/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -c /usr/src/lib/libc/gen/dlfcn.c -o dlfcn.o /usr/src/lib/libc/gen/disklabel.c: In function `getdiskbyname': /usr/src/lib/libc/gen/disklabel.c:147: `fstypenames' undeclared (first use in this function) /usr/src/lib/libc/gen/disklabel.c:147: (Each undeclared identifier is reported only once /usr/src/lib/libc/gen/disklabel.c:147: for each function it appears in.) /usr/src/lib/libc/gen/disklabel.c: In function `getdiskbyname': /usr/src/lib/libc/gen/disklabel.c:147: `fstypenames' undeclared (first use in this function) /usr/src/lib/libc/gen/disklabel.c:147: (Each undeclared identifier is reported only once *** Error code 1 /usr/src/lib/libc/gen/disklabel.c:147: for each function it appears in.) *** Error code 1 /usr/src/lib/libc/gen/disklabel.c: In function `getdiskbyname': /usr/src/lib/libc/gen/disklabel.c:147: `fstypenames' undeclared (first use in this function) /usr/src/lib/libc/gen/disklabel.c:147: (Each undeclared identifier is reported only once /usr/src/lib/libc/gen/disklabel.c:147: for each function it appears in.) *** Error code 1 3 errors *** Error code 2 1 error The following patch (from /usr/src) gets past the problem, but I don't know that it's correct: Index: lib/libc/gen/disklabel.c === RCS file: /cvs/freebsd/src/lib/libc/gen/disklabel.c,v retrieving revision 1.15 diff -u -r1.15 disklabel.c --- lib/libc/gen/disklabel.c12 May 2002 20:49:33 - 1.15 +++ lib/libc/gen/disklabel.c16 Aug 2002 14:39:03 - @@ -38,6 +38,7 @@ __FBSDID($FreeBSD: src/lib/libc/gen/disklabel.c,v 1.15 2002/05/12 20:49:33 phk Exp $); #include sys/param.h +#define FSTYPENAMES #define DKTYPENAMES #include sys/disklabel.h Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- === lib/libc /local0/scratch/des/src/lib/libc/gen/disklabel.c: In function `getdiskbyname': /local0/scratch/des/src/lib/libc/gen/disklabel.c:147: `fstypenames' undeclared (first use in this function) /local0/scratch/des/src/lib/libc/gen/disklabel.c:147: (Each undeclared identifier is reported only once /local0/scratch/des/src/lib/libc/gen/disklabel.c:147: for each function it appears in.) *** Error code 1 Stop in /local0/scratch/des/src/lib/libc. *** Error code 1 Stop in /local0/scratch/des/src/lib. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
According to Terry Lambert: There's always waiting for 3.3 to be released before trying to incorporate it... There are too many code generation bugs in our version right now. Some ports need 3.1.1 from ports (remember our gcc is 3.1-prerelease). I don't care about 3.2 or 3.3, but I'd say go for snap of 3.3 now, if you look at the ports gcc, gcc32 == gcc33 at the moment. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World breakage in lib/libc/gen/disklabel.c; here's a patch
Date: Fri, 16 Aug 2002 08:03:06 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] The following patch (from /usr/src) gets past the problem, but I don't know that it's correct: Still don't know about correct, but it was incomplete. Index: lib/libc/gen/disklabel.c After adding these patches to that one, I got world to build. (Building kernel as I type, so I haven't booted the result, let alone tested it.) Index: sbin/disklabel/disklabel.c === RCS file: /cvs/freebsd/src/sbin/disklabel/disklabel.c,v retrieving revision 1.56 diff -u -r1.56 disklabel.c --- sbin/disklabel/disklabel.c 3 Jul 2002 16:43:11 - 1.56 +++ sbin/disklabel/disklabel.c 16 Aug 2002 15:18:40 - @@ -60,6 +60,7 @@ #include sys/file.h #include sys/stat.h #include sys/wait.h +#define FSTYPENAMES #define DKTYPENAMES #include sys/disklabel.h #ifdef __sparc64__ Index: sbin/fsck_ffs/setup.c === RCS file: /cvs/freebsd/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.36 diff -u -r1.36 setup.c --- sbin/fsck_ffs/setup.c 16 Aug 2002 07:34:19 - 1.36 +++ sbin/fsck_ffs/setup.c 16 Aug 2002 15:28:35 - @@ -39,6 +39,7 @@ $FreeBSD: src/sbin/fsck_ffs/setup.c,v 1.36 2002/08/16 07:34:19 alfred Exp $; #endif /* not lint */ +#define FSTYPENAMES #include sys/param.h #include sys/stat.h #include sys/disklabel.h Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World breakage in lib/libc/gen/disklabel.c; here's a patch
* David Wolfskill [EMAIL PROTECTED] [020816 08:52] wrote: Date: Fri, 16 Aug 2002 08:03:06 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] The following patch (from /usr/src) gets past the problem, but I don't know that it's correct: Still don't know about correct, but it was incomplete. Index: lib/libc/gen/disklabel.c After adding these patches to that one, I got world to build. (Building kernel as I type, so I haven't booted the result, let alone tested it.) Sorry, I'll have this committed soon. Index: sbin/disklabel/disklabel.c === RCS file: /cvs/freebsd/src/sbin/disklabel/disklabel.c,v retrieving revision 1.56 diff -u -r1.56 disklabel.c --- sbin/disklabel/disklabel.c3 Jul 2002 16:43:11 - 1.56 +++ sbin/disklabel/disklabel.c16 Aug 2002 15:18:40 - @@ -60,6 +60,7 @@ #include sys/file.h #include sys/stat.h #include sys/wait.h +#define FSTYPENAMES #define DKTYPENAMES #include sys/disklabel.h #ifdef __sparc64__ Index: sbin/fsck_ffs/setup.c === RCS file: /cvs/freebsd/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.36 diff -u -r1.36 setup.c --- sbin/fsck_ffs/setup.c 16 Aug 2002 07:34:19 - 1.36 +++ sbin/fsck_ffs/setup.c 16 Aug 2002 15:28:35 - @@ -39,6 +39,7 @@ $FreeBSD: src/sbin/fsck_ffs/setup.c,v 1.36 2002/08/16 07:34:19 alfred Exp $; #endif /* not lint */ +#define FSTYPENAMES #include sys/param.h #include sys/stat.h #include sys/disklabel.h Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill[EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. -- -Alfred Perlstein [[EMAIL PROTECTED]] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: question about ipl.ko
On Fri, Aug 16, 2002 at 03:01:47PM +0200, Radko Keves wrote: i try to load ipl.ko #kldload -v /boot/kernel/ipl.ko kldload: can't load /boot/kernel/ipl.ko: Exec format error [snip] it's my problem, for example in the kernel module loading sequence, or current problem ? Both. If you are getting an 'Exec format error,' there is something wrong at your end. However, ipl.ko has been broken in CURRENT for a long time (over a year at least) and will not load (albeit with a different error message). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Proliferating quirk table entries
I'm working on cleaning up quirk entries in scsi_da.c, especially ones related to READ/WRITE 6-10 escalation. For those just joining in, there is a function (cmd6workaround) that handles a R/W6 error by translating the cdb to 10 bytes and restarting it. It also increases the command size that will be used to 10 so future R/W requests automatically work. This is obviously preferable to entering quirk entries for every USB device. This function has been tested for a while but it's still possible some equipment won't correctly handle the workaround. I am preparing to add a kernel option (DISABLE_CDB6_QUIRKS) that will default to off. It will disable the use of DA_Q_NO_6_BYTE to allow cmd6workaround to do its stuff. Users of equipment listed in the quirk table would be solicited to enable this kernel option and try their equipment again. If problems are found in the workaround code, I will attempt to fix them. If things work, that quirk can be removed. If you have alternative suggestions, let me know. NO_SYNC_CACHE will be next on my list. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
On Thu, 15 Aug 2002, dmk wrote:
Is anybody successfully using the port emulators/rtc with vmware2 on
-current?
[...]
On Thu, Aug 15, 2002 at 01:36:46PM -0400 Robert Watson wrote:
My recollection is that the problem relates to calling make_dev() from the
attach routine, and attach from the open call, and of course you can't
open before you make_dev with devfs. Someone needs to restructure the
driver to match some our other pseudo-device drivers where the device is
properly created as part of module initialization.
[...]
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
The attached diff effectively restructures the rtc device driver to
perform the make_dev() at module load. The driver may have problems, but
it does work, and, unlike the first diff, doesn't segfault on unload. ;-)
(I don't claim to write C or hack kernels, so this presented as-is in
that it works for me.)
Daniel M. Kurry
--- rtc.c.bkThu Aug 15 03:50:21 2002
+++ rtc.c Thu Aug 15 12:08:00 2002
@@ -77,6 +77,8 @@
static struct rtc_softc *rtc_sc=NULL;
+static dev_t rtc_dev=NULL;
+
static d_open_trtc_open;
static d_close_t rtc_close;
static d_ioctl_t rtc_ioctl;
@@ -115,43 +117,6 @@
/* -=-=-=-=-=-=-=-=-= attach/detach device stuff -=-=-=-=-=-=-=-=-= */
-static struct rtc_softc *
-rtc_attach(dev_t dev)
-{
- struct rtc_softc *sc;
- int unit;
-
-#if __FreeBSD_version = 500014
- unit = dev2unit(dev);
-#else
- unit = lminor(dev);
-#endif
- DLog(Lenter, %d %p, unit, dev);
- if (dev-si_drv1) {
- DLog(Lexit, old %p, %p, dev, dev-si_drv1);
- return dev-si_drv1;
- }
-
- if (rtc_sc!=NULL)
- return NULL;
-
- dev = make_dev(rtc_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600,
DEVICE_NAME);
- if (dev==NULL)
- return (NULL);
-
- MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
- if (sc==NULL)
- return NULL;
-
- bzero(sc, sizeof(*sc));
- rtc_sc = sc;
- dev-si_drv1 = sc; /* Link together */
- sc-dev = dev;
-
- DLog(Lexit, new %p,%p, dev, sc);
- return sc;
-}
-
static int
rtc_detach(struct rtc_softc *sc)
{
@@ -163,7 +128,7 @@
if (sc-var.flags.opened) {
return EBUSY;
}
- destroy_dev(sc-dev);
+ destroy_dev(rtc_sc-dev);
FREE(sc, M_DEVBUF);
return error;
}
@@ -177,9 +142,8 @@
rtc_open(dev_t dev, int oflag, int otyp, struct proc *p)
#endif
{
- struct rtc_softc *sc;
+ struct rtc_softc *sc = (struct rtc_softc *) dev-si_drv1;
- sc = rtc_attach(dev);
if (sc==NULL)
return (EAGAIN);
@@ -264,7 +228,21 @@
static int
init_module(void)
{
-int error;
+ int error;
+ struct rtc_softc *sc;
+
+ rtc_dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
+ if(rtc_dev==NULL)
+ return (NULL);
+
+ MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
+ if(sc==NULL)
+ return NULL;
+
+ bzero(sc, sizeof(*sc));
+ rtc_sc = sc;
+ rtc_dev-si_drv1 = rtc_sc; /* Link together */
+ rtc_sc-dev = rtc_dev;
error = cdevsw_add(rtc_cdevsw);
if (error)
Re: emulators/rtc and vmware2
On Fri, 16 Aug 2002, dmk wrote: On Thu, 15 Aug 2002, dmk wrote: Is anybody successfully using the port emulators/rtc with vmware2 on -current? [...] On Thu, Aug 15, 2002 at 01:36:46PM -0400 Robert Watson wrote: My recollection is that the problem relates to calling make_dev() from the attach routine, and attach from the open call, and of course you can't open before you make_dev with devfs. Someone needs to restructure the driver to match some our other pseudo-device drivers where the device is properly created as part of module initialization. [...] Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories The attached diff effectively restructures the rtc device driver to perform the make_dev() at module load. The driver may have problems, but it does work, and, unlike the first diff, doesn't segfault on unload. ;-) (I don't claim to write C or hack kernels, so this presented as-is in Generally it's more appropriate to do cdevsw_add() in module init and then make_dev() in each open. That's the ONLY way to do it if you have multiple instances of a device (e.g. BPF). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
On Fri, Aug 16, 2002 at 04:31:49PM -0700 I heard the voice of Nate Lawson, and lo! it spake thus: On Fri, 16 Aug 2002, dmk wrote: [...] The attached diff effectively restructures the rtc device driver to perform the make_dev() at module load. The driver may have problems, but it does work, and, unlike the first diff, doesn't segfault on unload. ;-) (I don't claim to write C or hack kernels, so this presented as-is in Generally it's more appropriate to do cdevsw_add() in module init and then make_dev() in each open. That's the ONLY way to do it if you have multiple instances of a device (e.g. BPF). Yes, but... ;-) That way doesn't work with VMware. The restructured way does. Unfortunately, I don't know enough about what's going on to fix it the Right Way, which I presume would involve fixing VMware. Can anyone suggest where I should be looking? -Nate dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vmware2 panic on -current
Recent -current (a couple days old) panics when i start
vmware2. Trace is attached. Any clue?
thanks
max
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 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-undermydesk-freebsd...
panic: bremfree: bp 0xc5536e30 not locked
panic messages:
---
panic: mutex vm page queue mutex not owned at ../../../vm/vm_page.c:1275
syncing disks... panic: bremfree: bp 0xc5536e30 not locked
Uptime: 1m18s
pfs_vncache_unload(): 5 entries remaining
/dev/vmmon: Module vmmon: unloaded
Dumping 191 MB
ata0: resetting devices ..
done
16 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] 64 80 96 112 128 144 160 176
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01934ed in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc0193718 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc01d41a7 in bremfree (bp=0xc02ea5e5) at ../../../kern/vfs_bio.c:633
#4 0xc02666f7 in ffs_fsync (ap=0xcaf4d81c) at ../../../ufs/ffs/ffs_vnops.c:213
#5 0xc0265d17 in ffs_sync (mp=0xc1812400, waitfor=2, cred=0xc0d70f00,
td=0xc0312f00) at vnode_if.h:545
#6 0xc01e6ab8 in sync (td=0xc0312f00, uap=0x0)
at ../../../kern/vfs_syscalls.c:129
#7 0xc019310c in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#8 0xc0193718 in panic () at ../../../kern/kern_shutdown.c:493
#9 0xc0189ffc in _mtx_assert (m=0xc02e2388, what=0,
file=0xc187bb40 À*¤Áø*¤Á, line=256) at ../../../kern/kern_mutex.c:800
#10 0xc02839e0 in vm_page_wire (m=0xc02e2388) at ../../../vm/vm_page.c:1275
#11 0xc182b79b in ?? ()
#12 0xc182b978 in ?? ()
#13 0xc182a374 in ?? ()
#14 0xc182b226 in ?? ()
#15 0xc0167a72 in spec_ioctl (ap=0xc02e2388)
at ../../../fs/specfs/spec_vnops.c:322
#16 0xc0167658 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:124
#17 0xc02729b8 in ufs_vnoperatespec (ap=0x0)
at ../../../ufs/ufs/ufs_vnops.c:2788
#18 0xc01ee5c1 in vn_ioctl (fp=0x100, com=3246897984, data=0xcaf4dc14,
td=0xc187bb40) at vnode_if.h:437
#19 0xc01b5f0c in ioctl (td=0xc187bb40, uap=0xcaf4dd10) at file.h:222
#20 0xc182ca5c in ?? ()
#21 0xc191bfba in ?? ()
#22 0xc02b9d41 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 136771792, tf_esi = 0, tf_ebp =
-1077937624, tf_isp = -889922188, tf_ebx = 10, tf_edx = 681095168, tf_ecx = 207,
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 675667748, tf_cs = 31, tf_eflags =
12946, tf_esp = -1077938716, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#23 0xc02aa78d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
why should buildworld touch stuff outside /usr/src ? (was Re:buildworld breakage)
On Fri, 16 Aug 2002 08:55:04 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: I ran into this also, and a bit of fiddling with a debugger was un-enlightening -- it was segfaulting on a write to __collate_substitute_table in parse.y. The pointer to the table didn't appear to be corrupted, and it should have been in writable memory. It also appeared to be properly aligned. I moved on to other stuff but was planning to submit a bug report if it persisted (and therefore wasn't a local nit of mine due to heavy local kernel mods). Ok I just updated to today's sources and it's gone. On the other hand I have another problem now. It seems buildworld touches stuff outside of /usr/src (specifically in /etc/mail). I noticed this behaviour some months ago but promptly forgot about it when I trashed my hard drive and had to rebuild my system. This is the first time since then (May/June) that I have tried running buildworld as a regular user. I would like to be able to continue doing everything short of install as a regular user. Is it really necessary to require root privs to buildworld? [ I've CCed gshapiro ] === usr.sbin/keyserv cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/keyserv.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/setkey.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c crypt_svc.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/crypt_server.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF -o keyserv ke yserv.o setkey.o crypt_svc.o crypt_server.o -lmp -lcrypto -lrpcsvc gzip -cn /daemon/build/current/src/usr.sbin/keyserv/keyserv.8 keyserv.8.gz === etc === etc/sendmail rm -f freebsd.cf (cd /daemon/build/current/src/etc/sendmail m4 -D_CF_DIR_=/daemon/build/curre nt/src/etc/sendmail/../../contrib/sendmail/cf/ /daemon/build/current/src/etc/s endmail/../../contrib/sendmail/cf/m4/cf.m4 freebsd.mc) freebsd.cf chmod 444 freebsd.cf rm -f /etc/mail/kokeb.ambesa.net.cf (cd /daemon/build/current/src/etc/sendmail m4 -D_CF_DIR_=/daemon/build/curre nt/src/etc/sendmail/../../contrib/sendmail/cf/ /daemon/build/current/src/etc/s endmail/../../contrib/sendmail/cf/m4/cf.m4 /etc/mail/kokeb.ambesa.net.mc) /etc /mail/kokeb.ambesa.net.cf cannot create /etc/mail/kokeb.ambesa.net.cf: permission denied *** Error code 2 Stop in /daemon/build/current/src/etc/sendmail. *** Error code 1 Stop in /daemon/build/current/src/etc. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. Cheers, Mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OT: Debian GNU/FreeBSD???
In article 002501c243e7$9c1ae5b0$[EMAIL PROTECTED], [EMAIL PROTECTED] writes: http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! Why? I thought FreeBSD wants no distros to avoid all the distrochaos Linux got right now. Debian is rather contraproductive to that. Luckily it aint popular. -mg I can't understand the resoning for even doing this. For the Linux userland (i.e., GNU utilities)? I _much_ prefer the FreeBSD userland... Dave -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: why should buildworld touch stuff outside /usr/src ? (was Re:buildworld breakage)
makonnen I would like to be able to continue doing everything short of
makonnen install as a regular user. Is it really necessary to require root
makonnen privs to buildworld?
Agreed. I haven't been able to come up with a way to convince make to
adjust the destination path according to the source path. Given this
subset of rules from /usr/src/etc/sendmail/Makefile:
.SUFFIXES: .mc .cf
.mc.cf: ${M4FILES}
${RM} ${.TARGET}
(cd ${.CURDIR} \
${M4} -D_CF_DIR_=${CFDIR}/ ${SENDMAIL_M4_FLAGS} \
${CFDIR}/m4/cf.m4 ${@:R}.mc) ${.TARGET}
${CHMOD} ${ROMODE} ${.TARGET}
SENDMAIL_MC=/etc/mail/foo.mc
SENDMAIL_ADDITIONAL_MC= /usr/local/etc/foo.mc
INSTALL_CF= ${SENDMAIL_MC:R}.cf
SENDMAIL_ADDITIONAL_CF= ${SENDMAIL_ADDITIONAL_MC:S/.mc$/.cf/g}
all:${INSTALL_CF} ${SENDMAIL_ADDITIONAL_CF}
Currently, /etc/mail/foo.cf and /usr/local/etc/foo.cf will be built.
I'd prefer /usr/obj/usr/src/etc/sendmail/etc/mail/foo.cf and
/usr/obj/usr/src/etc/sendmail/usr/local/etc/foo.cf be created during
buildworld and installed to /etc/mail/ and /usr/local/etc/ respectively
during installworld. (See /usr/src/etc/sendmail/Makefile for install
rules).
Any Makefile gurus out there who can help?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
