Do we still need portmap(8)?
It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ccd performance (was: [ GEOM tests ] vinum drives lost)
: a lot of information on how to use it. I generally recommend : using a stripe size of 1152 for multitasking loads. : :Sectors? Why particularly this value? It's described in 'tuning'. Basically you want a fairly large stripe to reduce multi-disk seeking when reading sequential files (that is, if you do not need the combined bandwidth of more then one drive for the sequential case), and you also want to use a stripe that does not cause meta-data (e.g. inodes and bitmaps) to wind up on just one drive, e.g. use 1152 instead of 1024. or you will wind up with unbalanced accesses. :ccd, but I know a lot of cheap hardware RAID arrays always read an :entire stripe at a time, which requires more memory and takes longer. :Have you checked ccd for this? : :Greg I've done extensive work on ccd. It does not try to read a whole stripe, it just breaks the I/O up as appropriate, issues duel-I/O for mirror writes, and tries to select a reasonable (single) side when doing a read from a mirrored area. I even have a little code in there to try to reduce unnecessary seeking when reading from a mirrored area. But, again, CCD is not trying to implement 'real' RAID. It can't rebuild a lost mirror drive, for example, and does not implement RAID-5. IMHO A real RAID controller with NVRAM should be used for those things. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? One certainly still needs portmap(8), in its rpcbind(8) name, for NFS. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm can not login on current
On Mon, 7 Oct 2002, suken woo wrote: xdm broken on current when login . i knew this is the pam module problem,but how could i fix it? Chances are, you built your X11 with an old -CURRENT system, and since then the ABI for the PAM stuff has changed in -CURRENT, so your old X11 no longer talks happily with your new PAM. Remove and rebuild X11 (specifically xdm) and see if that helps. Of course, you don't provide any real details as to what the failure mode is, making this a little hard to debug. You might want to take a look at /var/log/messages and see if xdm gives any specific errors. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New panic fun.
Decided to update my source tree today. Evidently this was not a bright
move. I built my kernel and whatnot, powered off (rebooting on my
laptop doesn't work...), and startx'ed. Then I ran mozilla.
poof
Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x8:0xc028db0f
stack pointer = 0x10:0xd1e1c9e4
frame pointer = 0x10:0xd1e1c9e4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 665 (mozilla-bin)
Uptime: 4m53s
Dumping 255 MB
ata0: resetting devices ..
done
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1 0xc0190a75 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0190c4c in poweroff_wait (junk=0xc0298468, howto=-773732132)
at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc012343d in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc01233e0 in db_command (last_cmdp=0xc02ca100, cmd_table=0xc0298468,
aux_cmd_tablep=0x104, aux_cmd_tablep_end=0xc26775b0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc01234ab in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc012599a in db_trap (type=9, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc027a982 in kdb_trap (type=9, code=0, regs=0xd1e1c9a4)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc0289358 in trap_fatal (frame=0xd1e1c9a4, eva=0)
at /usr/src/sys/i386/i386/trap.c:841
#9 0xc0288ebc in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -1078001648, tf_edi = -773731000, tf_esi =
-1033407056, tf_ebp = -773731868, tf_isp = -773731888, tf_ebx = 514, tf_edx =
-1033407056, tf_ecx = -773731696, tf_eax = -773731696, tf_trapno = 9, tf_err = 0,
tf_eip = -1071064305, tf_cs = 8, tf_eflags = 65538, tf_esp = -773731852, tf_ss =
-1071064388}) at /usr/src/sys/i386/i386/trap.c:643
#10 0xc027bd98 in calltrap () at {standard input}:98
#11 0xc028dabc in npxsetregs (td=0x0, addr=0x0)
at /usr/src/sys/i386/isa/npx.c:1000
#12 0xc028349d in set_fpcontext (td=0xc26775b0, mcp=0x0)
at /usr/src/sys/i386/i386/machdep.c:2230
#13 0xc0281ea0 in sigreturn (td=0xc26775b0, uap=0x0)
at /usr/src/sys/i386/i386/machdep.c:757
#14 0xc0289636 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 135491152, tf_ebp =
-1077942724, tf_isp = -773730956, tf_ebx = 677337812, tf_edx = 677337244, tf_ecx =
-1077942616, tf_eax = 344, tf_trapno = 22, tf_err = 2, tf_eip = 677510491, tf_cs = 31,
tf_eflags = 662, tf_esp = -1077942768, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#15 0xc027bded in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
And there you have it. I cannot begin to fathom what caused this. So far
it seems that only running mozilla causes it to occur.
I can supply more information if needed of course.
--
Carl Schmidt
[Random Quote]
Satellite Safety Tip #14:
If you see a bright streak in the sky coming at you, duck.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? No, I'm asking whether we have left behind both an old man page and an old binary. On closer examination, though, it looks like this is the result of installing a 4.7 system and immediately upgrading it to 5-CURRENT, so that the dates of the files looked pretty much the same. Sorry for that confusion. What's the recommended way of getting old binaries off the system? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? No, I'm asking whether we have left behind both an old man page and an old binary. On closer examination, though, it looks like this is the result of installing a 4.7 system and immediately upgrading it to 5-CURRENT, so that the dates of the files looked pretty much the same. Sorry for that confusion. What's the recommended way of getting old binaries off the system? I use: cd /usr/src make installworld DESTDIR=/some/where diff -ur /some/where / manual review. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ccd performance (was: [ GEOM tests ] vinum drives lost)
Matthew Dillon wrote: But, again, CCD is not trying to implement 'real' RAID. It can't rebuild a lost mirror drive, for example, and does not implement RAID-5. IMHO A real RAID controller with NVRAM should be used for those things. FWIW, the people who sell RAID controllers with NVRAM feel the same way about software RAID implementations... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/geom geom_disk.c
This patch may also fix problems on PC98 which as far as I know have 1k sector disks, so if some of the PC98 people could try it a GEOM kernel out now I would be grateful. Poul-Henning In message [EMAIL PROTECTED], Poul-Henning Kamp writes: phk 2002/10/07 00:15:37 PDT Modified files: sys/geom geom_disk.c Log: Correctly deal with non-DEVBSIZE drives. Allow BIO_DELETE through too. This fixes swap-backed md(4) devices. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Compilation of jdk with native threads failes
Error log is: === Recursively making native all @ Mon Oct 7 09:38:55 CEST 2002 ... gmake[3]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/native' gmake ../../../../build/bsd-i386/lib/i386/native_threads/libhpi.so VARIANT=OPT gmake[4]: Entering directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/native' /usr/bin/gcc -O -pipe -W -Wall -Wno-unused -Wno-parentheses -pthread -I/usr/src/lib/libc_r/uthread -I/usr/src/lib/libc/include -Di386 -DARCH='i386' -DSOLARIS2 -DRELEASE='1.3.1-p7' -DFULL_VERSION='1.3.1-p7-lutz-021007-09:38' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DLOGGING -D_LITTLE_ENDIAN -I. -I../../../../build/bsd-i386/tmp/java/hpi/native_threads/CClassHeaders -I../../../../src/solaris/javavm/export -I../../../../src/share/javavm/export -I../../../../src/solaris/hpi/native_threads/include -I../../../../src/solaris/hpi/include -I../../../../src/solaris/hpi/export -I../../../../src/share/hpi/include -I../../../../src/share/hpi/export -D_REENTRANT -DNATIVE -DUSE_PTHREADS -DMOOT_PRIORITIES -DNO_INTERRUPTIBLE_IO -c -o ../../../../build/bsd-i386/tmp/java/hpi/native_threads/obj/threads_bsd.o ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:287: warning: `enum pthread_susp' declared inside parameter list ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:287: warning: its scope is only this definition or declaration, which is probably not what you want ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:288: parameter `suspendState' has incomplete type ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:321: warning: initializer-string for array of chars is too long ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:321: warning: (near initialization for `SignalList[21]') ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:323: warning: excess elements in array initializer ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:323: warning: (near initialization for `SignalList') ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c: In function `record_gc_registers_of': ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:530: structure has no member named `ctxtype' ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:532: `CTX_JB_NOSIG' undeclared (first use in this function) ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:532: (Each undeclared identifier is reported only once ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:532: for each function it appears in.) ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:533: `CTX_JB' undeclared (first use in this function) ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:534: `CTX_SJB' undeclared (first use in this function) ../../../../src/solaris/hpi/native_threads/src/threads_bsd.c:540: `CTX_UC' undeclared (first use in this function) gmake[4]: *** [../../../../build/bsd-i386/tmp/java/hpi/native_threads/obj/threads_bsd.o] Error 1 gmake[4]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/native' gmake[3]: *** [optimized] Error 2 gmake[3]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi/native' gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java/hpi' gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/j2sdk1.3.1/make/java' gmake: *** [all] Error 1 *** Error code 2 Stop in /usr/ports/java/jdk13. === I cannot find the CTX_ constants and/or their meaning. Any hints? thanks Lutz To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm can not login on current
Robert Watson wrote: On Mon, 7 Oct 2002, suken woo wrote: ok, here's i get the messages Oct 7 00:38:18 wsk -:0 : unable to dlopen(/usr/lib/pam_nologin.so) Oct 7 00:38:18 wsk -:0 : [dlerror: /usr/lib/pam_nologin.so: Undefined symbol _openpam_log] Oct 7 00:38:18 wsk -:0 : adding faulty module: /usr/lib/pam_nologin.so Oct 7 00:38:18 wsk -:0 : unable to dlopen(/usr/lib/pam_unix.so) Oct 7 00:38:18 wsk -:0 : [dlerror: /usr/lib/pam_unix.so: Undefined symbol _openpam_log] Oct 7 00:38:18 wsk -:0 : adding faulty module: /usr/lib/pam_unix.so Oct 7 00:38:18 wsk -:0 : unable to dlopen(/usr/lib/pam_opie.so) Oct 7 00:38:18 wsk -:0 : [dlerror: /usr/lib/pam_opie.so: Undefined symbol _openpam_log] Oct 7 00:38:18 wsk -:0 : adding faulty module: /usr/lib/pam_opie.so Oct 7 00:38:18 wsk -:0 : unable to dlopen(/usr/lib/pam_opieaccess.so) Oct 7 00:38:18 wsk -:0 : [dlerror: /usr/lib/libopie.so.2: Undefined symbol __xuname] Oct 7 00:38:18 wsk -:0 : adding faulty module: /usr/lib/pam_opieaccess.so Oct 7 00:38:18 wsk -:0 : unable to dlopen(/usr/lib/pam_lastlog.so) Oct 7 00:38:18 wsk -:0 : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Oct 7 00:38:18 wsk -:0 : adding faulty module: /usr/lib/pam_lastlog.so xdm broken on current when login . i knew this is the pam module problem,but how could i fix it? Chances are, you built your X11 with an old -CURRENT system, and since then the ABI for the PAM stuff has changed in -CURRENT, so your old X11 no longer talks happily with your new PAM. Remove and rebuild X11 (specifically xdm) and see if that helps. Of course, you don't provide any real details as to what the failure mode is, making this a little hard to debug. You might want to take a look at /var/log/messages and see if xdm gives any specific errors. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compilation of jdk with native threads failes
On Mon, Oct 07, 2002 at 09:35:21AM +0200, Lutz Bichler wrote: I cannot find the CTX_ constants and/or their meaning. Any hints? I ran into this myself and it's because that stuff was delete recently in -current's libc_r. Another patch release needs to happen because of that to solve that problem. I have some changes in my tree, but it'll break the stuff that's suppose to work in -stable too, which is not recommend to be used. My suggestion is to just comment all of that stuff out so that it'll compile and use the HotSpot JIT instead. HotSpot is that only thing that really works anyways, so you're not losing anything essential by removing the ability to run -classic. -classic is dead anyways for client/server side stuff. The interruptable syscall (usleep(), read(), etc...) framework also needs to be reintegrated into HotSpot, since programs like Tomcat3 do funny thing with Thread.sleep(). Having a non-interruptable usleep() causes what looks like funny performance related problems, even though our JIT compiler is pretty severly jamming and is as good as gcc -O0 for stuff like Sieve calculations. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
On Oct 06 at 17:02, Terry Lambert spoke: You failed to delete the old header files when you upgraded your compiler. The easiest answer is man rm. 8-). Hm. I tought I had `*default delete use-rel-suffix' in the supfile. Do I still have to delete old files myself? Is /usr/include/stdlib.h obsolete? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Fwd: Re: xdm can not login on current]
---BeginMessage--- Robert Watson wrote: On Mon, 7 Oct 2002, suken woo wrote: xdm broken on current when login . i knew this is the pam module problem,but how could i fix it? Chances are, you built your X11 with an old -CURRENT system, and since then the ABI for the PAM stuff has changed in -CURRENT, so your old X11 no longer talks happily with your new PAM. Remove and rebuild X11 (specifically xdm) and see if that helps. Of course, you don't provide any real details as to what the failure mode is, making this a little hard to debug. You might want to take a look at /var/log/messages and see if xdm gives any specific errors. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories you are right! and btw could i use portupgrade X to fix it ? my xdm error messages: thanks any info To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ---End Message---
Re: stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
Hanspeter Roth wrote: On Oct 06 at 17:02, Terry Lambert spoke: You failed to delete the old header files when you upgraded your compiler. The easiest answer is man rm. 8-). Hm. I tought I had `*default delete use-rel-suffix' in the supfile. Doesn't matter. That only effects your CVS tree. A CVS update with the delete/prune options only effects your source tree. The problem is the installed header files, so changes to either your local CVS tree or your local source tree are irrelevent. Do I still have to delete old files myself? Yes. Is /usr/include/stdlib.h obsolete? /usr/include/* is obsolete. Install the new ones instead. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On Sun, Oct 06, 2002 at 11:14:26PM -0700, Terry Lambert wrote:
Stefan: Did the patch fix it, or not?
Sorry for the long delay. No, it did not. But I now have a rather
interesting core dump. I inserted a KASSERT, so that the code looks like
this:
TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
while (count) {
kn = TAILQ_FIRST(kq-kq_head);
KASSERT(kn != NULL, (TAILQ_FIRST returned NULL));
/*
* Skip over all markers which are not ours. This looks
* unsafe, but we can't hit the end of the list without
* hitting our own marker.
*/
while ((kn-kn_status KN_MARKER) (kn != marker)) {
kn = TAILQ_NEXT(kn, kn_tqe);
}
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
if (kn == marker) {
[...]
Script started on Mon Oct 7 11:26:10 2002
frog# ../bin/gdb -k crash/kernel.debug.3 crash/vmcore.3
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 0xd2adf6f0 not locked
panic messages:
---
panic: TAILQ_FIRST returned NULL
cpuid = 1; lapic.id = 0100
panic: from debugger
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... panic: bremfree: bp 0xd2adf6f0 not locked
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 13m27s
pfs_vncache_unload(): 1 entries remaining
Dumping 1023 MB
ata0: resetting devices ..
done
ad0: timeout sending command=c5 s=d0 e=00
ad0: error executing commandata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 doadump () at /freebsd/current/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) bt
#0 doadump () at /freebsd/current/src/sys/kern/kern_shutdown.c:223
#1 0xc01ba92a in boot (howto=260)
at /freebsd/current/src/sys/kern/kern_shutdown.c:355
#2 0xc01babe7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:508
#3 0xc01fcc77 in bremfree (bp=0xd2adf6f0)
at /freebsd/current/src/sys/kern/vfs_bio.c:632
#4 0xc01fe798 in vfs_bio_awrite (bp=0x3)
at /freebsd/current/src/sys/kern/vfs_bio.c:1633
#5 0xc02a7afa in ffs_fsync (ap=0xe2c9d8fc)
at /freebsd/current/src/sys/ufs/ffs/ffs_vnops.c:252
#6 0xc02a7829 in VOP_FSYNC (vp=0x0, cred=0x0, waitfor=0, td=0x0)
at vnode_if.h:612
#7 0xc02a6d3b in ffs_sync (mp=0xc642ba00, waitfor=2, cred=0xc22b2e80,
td=0xc03643a0) at /freebsd/current/src/sys/ufs/ffs/ffs_vfsops.c:1127
#8 0xc0210998 in sync (td=0xc03643a0, uap=0x0)
at /freebsd/current/src/sys/kern/vfs_syscalls.c:130
#9 0xc01ba52b in boot (howto=256)
at /freebsd/current/src/sys/kern/kern_shutdown.c:264
#10 0xc01babe7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:508
#11 0xc013b1d2 in db_panic () at /freebsd/current/src/sys/ddb/db_command.c:450
#12 0xc013b152 in db_command (last_cmdp=0xc035db40, cmd_table=0x0,
aux_cmd_tablep=0xc03577fc, aux_cmd_tablep_end=0xc0357800)
at /freebsd/current/src/sys/ddb/db_command.c:346
---Type return to continue, or q return to quit---
#13 0xc013b266 in db_command_loop ()
at /freebsd/current/src/sys/ddb/db_command.c:472
#14 0xc013deca in db_trap (type=3, code=0)
at /freebsd/current/src/sys/ddb/db_trap.c:72
#15 0xc02e9f60 in kdb_trap (type=3, code=0, regs=0xe2c9db94)
at /freebsd/current/src/sys/i386/i386/db_interface.c:166
#16 0xc0302027 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -968725664, tf_esi = 256, tf_ebp =
-490087456, tf_isp = -490087488, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1070685611, tf_cs = 8, tf_eflags = 658, tf_esp =
-1070272669, tf_ss = -1070406694})
at /freebsd/current/src/sys/i386/i386/trap.c:605
#17 0xc02eb768 in calltrap () at {standard input}:99
#18 0xc01babcf in panic (fmt=0x0)
at /freebsd/current/src/sys/kern/kern_shutdown.c:494
#19 0xc01a1212 in kqueue_scan (fp=0x0, maxevents=4, ulistp=0xbfbfeb90,
tsp=0xc754f828, td=0xc6426b60)
at /freebsd/current/src/sys/kern/kern_event.c:717
#20 0xc01a0ad1 in kevent (td=0xc6426b60, uap=0xe2c9dd10)
at /freebsd/current/src/sys/kern/kern_event.c:470
#21 0xc030299e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937792, tf_esi = 4, tf_ebp =
-1077941256, tf_isp = -490087052, tf_ebx = -1077937772, tf_edx = 2184, tf_---Type
return to continue, or q return to quit---
ecx = 0, tf_eax = 363, tf_trapno = 0, tf_err
alpha 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/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Oct 7 03:10:59 PDT 2002 -- Kernel build for GENERIC completed on Mon Oct 7 03:37:54 PDT 2002 -- Kernel build for LINT started on Mon Oct 7 03:37:55 PDT 2002 -- === vinum Makefile, line 4187: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
Hello, At 09:06 06/10/2002, Mikhail Teterin wrote: ... 218222592 total allocated this machine has a total of 512Mb of RAM, and no swap. No X was running. Just ``cvs update''-ing. I got this also a couple of times over the last week. It would panic every few days with this same message. I cvsupped/rebuilt 5 Oct, but it's only up for 14 hours. In any case, here's my dmesg. Also note the 'could sleep' warnings for if_xl. They have been there for over half a year I think. I've reported them before. There's also a duplicate lock in udp_usrreq that's new to me. Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Sun Oct 6 01:50:54 CEST 2002 [EMAIL PROTECTED]:/var/obj/usr/src/sys/TERMINUS Preloaded elf kernel /boot/kernel/kernel at 0xc04dc000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 233865126 Hz CPU: Pentium II/Pentium II Xeon/Celeron (233.87-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 67108864 (65536K bytes) avail memory = 59920384 (58516K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 6 entries at 0xc00fdc00 pcib0: Intel 82443LX (440 LX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 atapci0: Busmastering DMA not supported ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x6400-0x641f irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.3 (no driver attached) sym0: 875 port 0x6800-0x68ff mem 0xe800-0xe8000fff,0xe8001000-0xe80010ff irq 12 at device 11.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. xl0: 3Com 3c905-TX Fast Etherlink XL port 0x6c00-0x6c3f irq 9 at device 13.0 on pci0 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1264 lock order reversal 1st 0xc0ba1bd4 xl0 (network driver) @ /usr/src/sys/pci/if_xl.c:1264 2nd 0xc03d2b00 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:318 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1264 xl0: Ethernet address: 00:60:08:a5:d4:ff miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:647 pci0: display, VGA at device 15.0 (no driver attached) orm0: Option ROMs at iomem 0xc8000-0xcbfff,0xc-0xc7fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 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 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0501 can't assign resources (port) Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging unlimited Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. Mounting root from ufs:/dev/da0s1a da2 at sym0 bus 0 target 3 lun 0 da2: QUANTUM FIREBALL_TM3200S 300N Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 3067MB (6281856
Re: [PATCH] Re: Junior Kernel Hacker page updated...
Stefan Farfeleder wrote:
On Sun, Oct 06, 2002 at 11:14:26PM -0700, Terry Lambert wrote:
Stefan: Did the patch fix it, or not?
Sorry for the long delay. No, it did not. But I now have a rather
interesting core dump. I inserted a KASSERT, so that the code looks like
this:
TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
while (count) {
kn = TAILQ_FIRST(kq-kq_head);
KASSERT(kn != NULL, (TAILQ_FIRST returned NULL));
[ ... ]
panic: bremfree: bp 0xd2adf6f0 not locked
Second panic, during debugger sync.
panic: TAILQ_FIRST returned NULL
See below...
panic: from debugger
You, manually calling panic inside the debugger...
syncing disks... panic: bremfree: bp 0xd2adf6f0 not locked
The second panic (again).
#2 0xc01babe7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:508
2nd panic.
#10 0xc01babe7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:508
Manual panic (no arguments).
#18 0xc01babcf in panic (fmt=0x0)
at /freebsd/current/src/sys/kern/kern_shutdown.c:494
#19 0xc01a1212 in kqueue_scan (fp=0x0, maxevents=4, ulistp=0xbfbfeb90,
tsp=0xc754f828, td=0xc6426b60)
at /freebsd/current/src/sys/kern/kern_event.c:717
*** OK, it's very hard to believe you didn't break into the
*** debugger and manually call pnaic to get this to happen.
Why? Because the fmt string is 0x0, which indicates that you
called the panic manually, instead of being the address of the
string TAILQ_FIRST returned NULL, like you'd expect.
#19 0xc01a1212 in kqueue_scan (fp=0x0, maxevents=4, ulistp=0xbfbfeb90,
tsp=0xc754f828, td=0xc6426b60)
at /freebsd/current/src/sys/kern/kern_event.c:717
717 KASSERT(kn != NULL, (TAILQ_FIRST returned NULL));
(kgdb) info locals
kq = (struct kqueue *) 0xc754f800
kevp = (struct kevent *) 0xc754f828
atv = {tv_sec = 0, tv_usec = 0}
rtv = {tv_sec = 434, tv_usec = -1070420864}
ttv = {tv_sec = 1, tv_usec = -1070411616}
kn = (struct knote *) 0x0
marker = {kn_link = {sle_next = 0xc01b0d37}, kn_selnext = {
sle_next = 0xc0368a20}, kn_tqe = {tqe_next = 0x0, tqe_prev = 0xc6650ac8},
kn_kq = 0xc6426bcc, kn_kevent = {ident = 3344374324, filter = -30080,
flags = 49206, fflags = 3224546432, data = 431, udata = 0xe2c9dca0},
kn_status = 16, kn_sfflags = -1070167424, kn_sdata = 8, kn_ptr = {
p_fp = 0xc032ac80, p_proc = 0xc032ac80}, kn_fop = 0x1af, kn_hook = 0x3}
count = 4
timeout = 0
nkev = 0
error = 0
(kgdb) p *kq
$2 = {kq_head = {tqh_first = 0x0, tqh_last = 0xc754f800}, kq_count = 1,
kq_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0,
si_note = {slh_first = 0x0}, si_flags = 0}, kq_fdp = 0xc7571a00,
kq_state = 0, kq_kev = {{ident = 23, filter = -1, flags = 1, fflags = 0,
data = 69, udata = 0x80cd800}, {ident = 23, filter = -1, flags = 1,
fflags = 0, data = 164, udata = 0x80cd800}, {ident = 27, filter = -1,
flags = 1, fflags = 0, data = 218, udata = 0x80cf800}, {ident = 19,
filter = -1, flags = 1, fflags = 0, data = 182, udata = 0x80cc800}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}}}
(kgdb) q
frog# ^Dexit
Script done on Mon Oct 7 11:32:50 2002
I'm confused why marker - if it was removed by TAILQ_REMOVE - hasn't
kn_tqe.tqe_next and kn_tqe.tqe_prev set to (void *)-1.
OK, what this means is that the marker queue entry was removed
by something else going in there.
THis shouldn't happen.
Try adding this before the initialization of the marker data:
bzero(marker, sizeof(marker));
That should keep it from matching any removal criteria. THe only
way this could keep crashing after this mod is if the queue is
being destroyed out from under you.
The implication here is that the queue should be protected by the
object lock for the object for which the pointer to the queue
instance is an element.
Fixing this would be very hard (IMO).
The next step (assuming it still panics) is to add:
#define KQ_FREE 0x80
...and set it into kq_state on a kqueue that has been freed and/or
deallocated somewhere (then check to see if it's set, after the
panic). Ugly, but it will tell you whether or not that's what's
happening (scanning a dead queue).
The worst case is scanning a dead queue quose memory has been
reused for some other purpose. 8-(.
I can't personally repeat the problem, so you're elected to do
the legwork on this one. 8-(.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On Mon, 7 Oct 2002, Terry Lambert wrote: Stefan Farfeleder wrote: I'm confused why marker - if it was removed by TAILQ_REMOVE - hasn't kn_tqe.tqe_next and kn_tqe.tqe_prev set to (void *)-1. because that only happens if the debug code in queue.h is enabled, which it is not.. OK, what this means is that the marker queue entry was removed by something else going in there. THis shouldn't happen. Try adding this before the initialization of the marker data: bzero(marker, sizeof(marker)); That should keep it from matching any removal criteria. THe only way this could keep crashing after this mod is if the queue is being destroyed out from under you. The implication here is that the queue should be protected by the object lock for the object for which the pointer to the queue instance is an element. Fixing this would be very hard (IMO). The next step (assuming it still panics) is to add: #define KQ_FREE 0x80 ...and set it into kq_state on a kqueue that has been freed and/or deallocated somewhere (then check to see if it's set, after the panic). Ugly, but it will tell you whether or not that's what's happening (scanning a dead queue). The worst case is scanning a dead queue quose memory has been reused for some other purpose. 8-(. I can't personally repeat the problem, so you're elected to do the legwork on this one. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? I've always looked for files older than the last installworld and moved them aside thinking that they're obsolete. ( aside, not delete, just in case ) --On Monday, October 07, 2002 8:51 AM +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? No, I'm asking whether we have left behind both an old man page and an old binary. On closer examination, though, it looks like this is the result of installing a 4.7 system and immediately upgrading it to 5-CURRENT, so that the dates of the files looked pretty much the same. Sorry for that confusion. What's the recommended way of getting old binaries off the system? I use: cd /usr/src make installworld DESTDIR=/some/where diff -ur /some/where / manual review. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/usr/include/stdlib.h:51: syntax error before size_t
On Oct 07 at 02:43, Terry Lambert spoke: /usr/include/* is obsolete. Install the new ones instead. When I rename /usr/include and copy /usr/src/include/* to /usr/include I get: === usr.bin/yacc /usr/obj/usr/src/i386/usr/src/usr.bin/yacc created for /usr/src/usr.bin/yacc rm -f .depend mkdep -f .depend -a-D__FBSDID=__RCSID /usr/src/usr.bin/yacc/closure.c /usr/src/usr.bin/yacc/error.c /usr/src/usr.bin/yacc/lalr.c /usr/src/usr.bin/yacc/lr0.c /usr/src/usr.bin/yacc/main.c /usr/src/usr.bin/yacc/mkpar.c /usr/src/usr.bin/yacc/output.c /usr/src/usr.bin/yacc/reader.c /usr/src/usr.bin/yacc/skeleton.c /usr/src/usr.bin/yacc/symtab.c /usr/src/usr.bin/yacc/verbose.c /usr/src/usr.bin/yacc/warshall.c /usr/src/usr.bin/yacc/closure.c:43:23: sys/cdefs.h: No such file or directory When I copy /usr/src/include/* over the existing /usr/include I get: === usr.bin/yacc /usr/obj/usr/src/i386/usr/src/usr.bin/yacc created for /usr/src/usr.bin/yacc rm -f .depend mkdep -f .depend -a-D__FBSDID=__RCSID /usr/src/usr.bin/yacc/closure.c /usr/src/usr.bin/yacc/error.c /usr/src/usr.bin/yacc/lalr.c /usr/src/usr.bin/yacc/lr0.c /usr/src/usr.bin/yacc/main.c /usr/src/usr.bin/yacc/mkpar.c /usr/src/usr.bin/yacc/output.c /usr/src/usr.bin/yacc/reader.c /usr/src/usr.bin/yacc/skeleton.c /usr/src/usr.bin/yacc/symtab.c /usr/src/usr.bin/yacc/verbose.c /usr/src/usr.bin/yacc/warshall.c echo yacc: /usr/lib/libc.a .depend cc -O -pipe-D__FBSDID=__RCSID -c /usr/src/usr.bin/yacc/closure.c In file included from /usr/src/usr.bin/yacc/closure.c:46: /usr/include/stdlib.h:51: syntax error before size_t Is there something more to consider before building world? Did I copy the wrong include directory (/usr/src/include)? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm can not login on current
On Mon, 7 Oct 2002, suken woo wrote: xdm broken on current when login . i knew this is the pam module problem,but how could i fix it? Chances are, you built your X11 with an old -CURRENT system, and since then the ABI for the PAM stuff has changed in -CURRENT, so your old X11 no longer talks happily with your new PAM. Remove and rebuild X11 (specifically xdm) and see if that helps. Of course, you don't provide any real details as to what the failure mode is, making this a little hard to debug. You might want to take a look at /var/log/messages and see if xdm gives any specific errors. Yup, looks like your xdm needs rebuilding. Did you try that and see what happens? One hazard to running -CURRENT is occasionally you become obliged to rebuild lots of applications when assumptions change.. Most people bumped into this a few months ago, I think, so perhaps you just updated world recently? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Mon, 7 Oct 2002, Joel M. Baldwin wrote: Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? I've always looked for files older than the last installworld and moved them aside thinking that they're obsolete. ( aside, not delete, just in case ) Well, mostly all. (1) If a file is removed from the source tree, it won't be replaced, it will just get stale. That's what happened with grog's portmap and portmap.8.gz. Even more annoying are the man cache files which also need to be flushed. (2) Symlinks and directories are not replaced. If you do ls -l in lib, you'll see that the old files are (a) obsoleted libraries or library versions, and (b) the symlinks. Depending on what applications are present in your system, you may be able to flush (a), but be cautious about (b). Note that the caution regarding (a) is because old libraries may still be used by old dynamically linked applications. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/include/stdlib.h:51: syntax error before size_t
On Oct 07 at 02:43, Terry Lambert spoke: /usr/include/* is obsolete. Install the new ones instead. When I rename /usr/include and copy /usr/src/include/* to /usr/include I get: Don't do that. Look in src/Makefile* for the right way to fix your includes. (IIRC there is a target, maybe called doincludes to do this). M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/include/stdlib.h:51: syntax error before size_t
On Mon, Oct 07, 2002 at 02:17:00PM +0100, Mark Murray wrote: On Oct 07 at 02:43, Terry Lambert spoke: /usr/include/* is obsolete. Install the new ones instead. When I rename /usr/include and copy /usr/src/include/* to /usr/include I get: Don't do that. Look in src/Makefile* for the right way to fix your includes. (IIRC there is a target, maybe called doincludes to do this). I think it is called 'includes' which does 'buildincludes' and 'installincludes'. ciao, -robert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cheap Cigarettes
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D7_70E05A4E.D4244E03
Re: tcsh hang in -current (kse bug?)
On Sun, Oct 06, 2002 at 04:10:55PM -0700, Kris Kennaway wrote: Can anyone else reproduce this in tcsh? rpcgen -s `perl -e 'print ax5'` Word too long. I reported this to the tcsh people about 18 months ago, but I don't think it was ever fixed. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
From: Poul-Henning Kamp [EMAIL PROTECTED] In message [EMAIL PROTECTED], Seth Hieronymus writes: You were right. After trying both a CD, and a zip-disk in the computer (both together, and separately), having a zip-disk in the drive seems to allow the boot to continue normally. ATA(PI) or SCSI interface ZIP ? atapi. Here are some excerpts from the dmesg: atapci0: Intel PIIX4 ATA33 controller port 0x10c0-0x10cf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pci0: multimedia at device 15.1 (no driver attached) pci0: multimedia, audio at device 16.0 (no driver attached) pci0: input device at device 16.1 (no driver attached) pci0: serial bus, FireWire at device 17.0 (no driver attached) ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Thanks, Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Mon, Oct 07, 2002 at 04:32:10AM -0700, Joel M. Baldwin wrote: Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? It depends. If you have INSTALL='install -C in /etc/make.conf, then some (or even all) of the files in the named directories will not be replaced. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Mon, Oct 07, 2002 at 08:39:06AM -0600, Seth Hieronymus wrote: afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 PHK had me dd if=/dev/afd0 of=/dev/null with no media in the drive. I get dd: /dev/afd0: Device busy, which is what the problem is. Some where in /sys/dev/ata is an EBUSY that should be ENXIO. If you can instrument at least atapi-all.c and atapi-fd.c and help track this down it would be most helpful. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Oct 07, 2002 at 08:39:06AM -0600, Seth Hieronymus wrote: afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 PHK had me dd if=/dev/afd0 of=/dev/null with no media in the drive. I get dd: /dev/afd0: Device busy, which is what the problem is. Some where in /sys/dev/ata is an EBUSY that should be ENXIO. If you can instrument at least atapi-all.c and atapi-fd.c and help track this down it would be most helpful. I talked with sos@ about this today, and I'll be working on something tonight. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make includes
On Oct 07 at 14:17, Mark Murray spoke: Look in src/Makefile* for the right way to fix your includes. (IIRC there is a target, maybe called doincludes to do this). I made `includes' and then `libraries'. Now `buildworld' succeeded! Thanks. How did you know this? Is there a guide how to upgrade from stable to current? (src/UPDATING only mentions something about /usr/include/g++.) -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make includes
I made `includes' and then `libraries'. Now `buildworld' succeeded! Thanks. How did you know this? I read the makefiles. Is there a guide how to upgrade from stable to current? (src/UPDATING only mentions something about /usr/include/g++.) No. CURRENT is not really documented that way. Developers are supposed to Use the Source, Luke! :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken ata/ad%d.
After cleaning out some OBE(?) patches, the closest I can get my Libretto 110CT to booting a really recent CURRENT is terminated by a panic. Hand-written backtrace is: Debugger() panic() acpi_read_ivar() ata_dma_init() Here is the fix: Index: acpi.c === RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.75 diff -u -d -r1.75 acpi.c --- acpi.c 6 Sep 2002 17:01:06 - 1.75 +++ acpi.c 7 Oct 2002 13:41:45 - @@ -578,6 +578,7 @@ case ISA_IVAR_VENDORID: case ISA_IVAR_SERIAL: case ISA_IVAR_COMPATID: +case ISA_IVAR_IRQ: *(int *)result = -1; break; M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any users of matcd(4), mcd(4), or scd(4)?
On 07-Oct-2002 Paul Mather wrote: On Thu, Oct 03, 2002 at 05:01:07PM -0400, John Baldwin wrote: = [...] Note = that if support for these ancient devices was dropped, it wouldn't = be dropped until 5.0. 4.x. would continue to support these devices = forever. During my last cvsup (I track 4.x-STABLE [RELENG_4]), I noticed that the /usr/src/sys/i386/isa/matcd directory was deleted. When I browsed the CVS repository, it appeared that matcd support was axed on Oct. 5th, somewhat contradicting the notion that 4.x would continue to support these devices. :-\ I can appreciate matcd being dropped for 5.0 on pragmatic grounds, but it would have been nice to have it ride out the rest of 4.x, given that it actually works right now. (As I understand it, it's the adoption of GEOM that signalled the death knell of these old drivers, but GEOM is a 5.x feature that wouldn't be MFC'd back to 4.x...) Unfortunately there were other issues with the driver unrelated to GEOM that required its removal. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ 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 -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Oct 7 09:41:04 PDT 2002 -- === xe ./aicasm: 877 instructions used ./aicasm: 686 instructions used cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** 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
Familiar?
cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/dell/imp/p4/newcard/src/lib/libkvm -c /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:327: `KI_MTXBLOCK' undeclared (first use in this function) /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:327: (Each undeclared identifier is reported only once /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:327: for each function it appears in.) /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:328: structure has no member named `td_mtxname' /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:330: structure has no member named `td_mtxname' /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:331: structure has no member named `ki_mtxname' /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:331: `MTXNAMELEN' undeclared (first use in this function) /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:332: structure has no member named `ki_mtxname' /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:359: `SMTX' undeclared (first use in this function) *** Error code 1 This is with last night's sources. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
loader problem
Hi, after an installworld with last night's sources, my machine resets in the the loader. It prints the BTX loader line, and then immediately resets. I restored the old /boot/loader (from 10/2), which lets me boot again. Any ideas? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Do we still need portmap(8)?
M. Warner Losh writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sorry state of Xserver in 5.0
Every so often, my X server locks up. It seems to be in a tight loop, 95% user time, and making only these ktrace'able calls: 27069 XFree86 0.019988 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 27069 XFree86 0.39 CALL sigreturn(0xbd9e7b0c) 27069 XFree86 0.04 RET sigreturn JUSTRETURN 27069 XFree86 0.019951 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 27069 XFree86 0.15 CALL sigreturn(0xbd9e6e0c) 27069 XFree86 0.04 RET sigreturn JUSTRETURN 27069 XFree86 0.019980 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 Anybody have a workaround for this? The whole system (2.53 Ghz P4) was compiled from sources late last week... Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. Sigh. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader problem
Lars Eggert wrote: after an installworld with last night's sources, my machine resets in the the loader. It prints the BTX loader line, and then immediately resets. I restored the old /boot/loader (from 10/2), which lets me boot again. Any ideas? The same happens on my laptop (installed from the same build), so it's not specific to one kind of hardware. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. Having something that warns may be a good idea. Having something that auto-deletes less so. I sometimes keep old stuff on purpose to prevent foot-shooting when the replacement is not up to scratch. No objection if mergemaster asks permission to delete stuff, for example. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
This sounds very similar to a problem I am seeing that does not result in a fatal lockup, but rather several minutes of complete unresponsiveness. It only seems to happen when Konqueror tries to autocomplete from the location bar. On Mon, 7 Oct 2002, Andrew Gallatin wrote: Every so often, my X server locks up. It seems to be in a tight loop, 95% user time, and making only these ktrace'able calls: 27069 XFree86 0.019988 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 27069 XFree86 0.39 CALL sigreturn(0xbd9e7b0c) 27069 XFree86 0.04 RET sigreturn JUSTRETURN 27069 XFree86 0.019951 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 27069 XFree86 0.15 CALL sigreturn(0xbd9e6e0c) 27069 XFree86 0.04 RET sigreturn JUSTRETURN 27069 XFree86 0.019980 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 Anybody have a workaround for this? The whole system (2.53 Ghz P4) was compiled from sources late last week... Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. Sigh. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
Wesley Morgan writes: This sounds very similar to a problem I am seeing that does not result in a fatal lockup, but rather several minutes of complete unresponsiveness. It only seems to happen when Konqueror tries to autocomplete from the location bar. I'm not really sure what was happening when I triggered it. I'll try taking a deep breath and waiting a few minutes. From running top on a remote machine, it appeared that X kept on growing and growing.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Joel M. Baldwin wrote: Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? They are replaced... if they exist boith before and afterward. They are also created... if they did not exist before, but do exist afterward. What's not done is that they are not *removed*... if they existed before, but were not recreated. Note that every port or package installed on your system, and every file in every user directory, also does not exist as a result of the source tree. Therefore removing everything that is not a result of the source tree would be... Bad(tm). I've always looked for files older than the last installworld and moved them aside thinking that they're obsolete. ( aside, not delete, just in case ) Yes. And you will have to continue to do so. Base system component files are not removed when they are made obsolete, because they are not registered anywhere, and thus their obsolete status is not known. Consider the case of a *new* compat-4 library for 5.x, which is required for certain 4.x programs to run, or Perl, which is a port/package in 5.x, rather than a base system component. You cannot just remove bas system components because they no longer exist, when you have software which depends on them, unless you re-track the dependencies, and force the install of the now-optional components. For Perl, this is not as hard as for compat-4, or something similar, which will be dependend upon by programs which are not identified to the package managements system, even if you (empasis on _you_) were to do the work to register the rest of the OS into the package management system. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/include/stdlib.h:51: syntax error before size_t
Hanspeter Roth wrote: On Oct 07 at 02:43, Terry Lambert spoke: /usr/include/* is obsolete. Install the new ones instead. When I rename /usr/include and copy /usr/src/include/* to /usr/include I get: What happens when you read the -current archives for other messages which indicate the same problem, and then use the correct procedure for installing new include files, instead? 8-). Did I copy the wrong include directory (/usr/src/include)? Yes. You weren't supposed to copy, you were suppose to use the make target. Include files are generated, or they come from all over, not just the source directory for the simple includes. -- To save you the minute and a half of searching (which is apparently what you want somone to do -- why are you asking in -current instead of -questions?): cd /usr mv include include.old mkdir include chown root.wheel include chmod 755 include cd /usr/src make includes The mkdir/chode/chmod is necessary because the includes target fails to create its install directory (one of many minor broken things about the build process). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Daniel Flickinger wrote: Name: text textType: Plain Text (text/plain) Encoding: 7bit As an EMACS afficionado, perhaps I can get you to fix AtillaMail? Right now, even without attachments other than the message body, it adds: Content-Type: text/plain; charset=iso-8859-1; name=text Content-Transfer-Encoding: 7bit Content-Disposition: inline The correct thing to do is to claim the character set is us-ascii and/or to use 8bit, base64, or quoted-printable transfer encoding. As it is, everyone who has any intelligence at all has to manually go through an additional step to decode your message bodies, since they have their mainl clients configured to avoid automatic invocation and retransmission of worms and other programs. Thanks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any users of matcd(4), mcd(4), or scd(4)?
John Baldwin wrote: I can appreciate matcd being dropped for 5.0 on pragmatic grounds, but it would have been nice to have it ride out the rest of 4.x, given that it actually works right now. (As I understand it, it's the adoption of GEOM that signalled the death knell of these old drivers, but GEOM is a 5.x feature that wouldn't be MFC'd back to 4.x...) Unfortunately there were other issues with the driver unrelated to GEOM that required its removal. What are these? I've read the license, and it doesn't appear to be a license issue... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any users of matcd(4), mcd(4), or scd(4)?
On Mon, Oct 07, 2002 at 01:26:50PM -0700, Terry Lambert wrote: John Baldwin wrote: I can appreciate matcd being dropped for 5.0 on pragmatic grounds, but it would have been nice to have it ride out the rest of 4.x, given that it actually works right now. (As I understand it, it's the adoption of GEOM that signalled the death knell of these old drivers, but GEOM is a 5.x feature that wouldn't be MFC'd back to 4.x...) Unfortunately there were other issues with the driver unrelated to GEOM that required its removal. What are these? I've read the license, and it doesn't appear to be a license issue... Terry, Please be sure that you are not confusing 'matcd' with 'mcd'. The former has a 10 clause license and is not suitable for use in FreeBSD any more. The latter has a traditional 4 clause BSD license and is not scheduled for removal. In fact, there is at least one person doing active maintenance on it. Folks, I mourned the passing of matcd, too. It supported the first CD-ROM drive I owned. However, it is a closed issue. I encourage anyone who still desired support for this hardware to investigate other code bases which we could leverage off of, as long as the licensing issues involved are well understood and amenible. Please do not let it distract from the progress we are making towards the 5.0 release. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Intended Audience
On Oct 07 at 16:44, Mark Murray spoke: How did you know this? I read the makefiles. This sounds like several hours of work. Thank you for letting me benefit of your time. No. CURRENT is not really documented that way. Developers are supposed to Use the Source, Luke! :-) So the intended audience for CURRENT are developers? Or maybe also testers? What if somebody wants to know whether his hardware configuration is supported (supposed it's not supported by Stable)? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Intended Audience
On Mon, Oct 07, 2002 at 11:06:13PM +0200, Hanspeter Roth wrote: No. CURRENT is not really documented that way. Developers are supposed to Use the Source, Luke! :-) So the intended audience for CURRENT are developers? Or maybe also testers? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html Kris msg44212/pgp0.pgp Description: PGP signature
Re: Intended Audience
* De: Hanspeter Roth [EMAIL PROTECTED] [ Data: 2002-10-07 ] [ Subjecte: Intended Audience ] No. CURRENT is not really documented that way. Developers are supposed to Use the Source, Luke! :-) So the intended audience for CURRENT are developers? Or maybe also testers? What if somebody wants to know whether his hardware configuration is supported (supposed it's not supported by Stable)? CURRENT is explicitly for developers, etc. Please read the page on the FreeBSD website. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Intended Audience
On Oct 07 at 16:44, Mark Murray spoke: How did you know this? I read the makefiles. This sounds like several hours of work. 5 minutes, actually. Thank you for letting me benefit of your time. Pleasure! No. CURRENT is not really documented that way. Developers are supposed to Use the Source, Luke! :-) So the intended audience for CURRENT are developers? Mostly, yes. Or maybe also testers? Them as well. What if somebody wants to know whether his hardware configuration is supported (supposed it's not supported by Stable)? Try current by al means, but as the hadbook states, CURRENT is not for those seeking new features. It is a development-heavy, support- light codebase. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Archie Cobbs wrote: M. Warner Losh writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. How will this work for perl, which is not removed, but is instead replaced with a stub shell script? I guess you can live with binaries linked against older versions of shared libraries suddenly not functioning... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/include/stdlib.h:51: syntax error before size_t
On 2002-10-07 14:17, Mark Murray [EMAIL PROTECTED] wrote: On Oct 07 at 02:43, Terry Lambert spoke: /usr/include/* is obsolete. Install the new ones instead. When I rename /usr/include and copy /usr/src/include/* to /usr/include I get: Don't do that. Look in src/Makefile* for the right way to fix your includes. (IIRC there is a target, maybe called doincludes to do this). By grepping through buildworld logs I saw this passing by: # cd /usr/src/include; make buildincludes; make installincludes That might help a bit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Terry Lambert writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. How will this work for perl, which is not removed, but is instead replaced with a stub shell script? Anything that gets overwritten during the normal install process is already taken care of. We're just trying to get rid of files which are not installed by 'make installword' but used to be once. I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader problem
Quoting Lars Eggert [EMAIL PROTECTED]: | Hi, | | after an installworld with last night's sources, my machine resets in | the the loader. It prints the BTX loader line, and then immediately | resets. I restored the old /boot/loader (from 10/2), which lets me boot | again. | | Any ideas? | I just had the same thing happen. ed - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Archie Cobbs wrote: How will this work for perl, which is not removed, but is instead replaced with a stub shell script? Anything that gets overwritten during the normal install process is already taken care of. We're just trying to get rid of files which are not installed by 'make installword' but used to be once. I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. This won't work for Perl (which is why I picked it as my example). In order to do what you are suggesting, you will need to create a delta between previously installed binaries and currently installed binaries, and remove anything not in the intersection set, but in the set of previously installed binaries. That would include perl and older shared library instances, not just header files that are stale, etc.. Older shared libraries being removed would break things. Older portmap being removed would break the startup scripts that referenced portmapper instead of rpc.bind -- unless they were *also* overwritten. You overwrite things which are in the intersection set with new binaries. And you install new binariers that didn't exist before: anything not in the intersection set, but in the set of newly installed binaries. The intersection case is problematic, in that you would overwrite your old, real perl with a shell script stub, which also makes perl a good example for this experiment. The last case is not a problem, since it's new stuff (of course). Even starting today, if you had a packing list for the next 4.x release, so that you could differentiate what went away from what was not installed from new stuff, it doesn't help existing installations that are trying to upgrade from source. This has kind of been discussed before; really, you have to teach the binary revision management tools about the base system; for perl, in particular, this lets you install the port version when you know you are upgrading from something with a system version and something with a system stub that doesn't work (really, you want a package version, not a port version, for this -- forcing the build of the package as part of the build of the system, as painful as that sounds). The same thing applied to installing a compat4 when upgrading from 4.x to 5.x. The user is then free to manually deinstall the compat4 package, if they do not require it. Personally, I've already been screwed multiple times on libc not having a version number bump, when the X binary distribution for 4.x is attempted to be run on 5.x (the simplest example is the resize program, which fails due to undefined symbols). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Archie Cobbs [EMAIL PROTECTED] writes: : I.e., if a file is not installed by 'make installworld' then by : definition it's not required for a correctly functioning system. The only exceptions to this rule would be if something was once in the system, but is now a port Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Terry Lambert writes: I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. This won't work for Perl (which is why I picked it as my example). In order to do what you are suggesting, you will need to create a delta between previously installed binaries and currently installed binaries, and remove anything not in the intersection set, but in the set of previously installed binaries. That would include perl and older shared library instances, not just header files that are stale, etc.. Older shared libraries being removed would break things. Older portmap being removed would break the You are right in that additional programs or custom modifications that depend on the obsolete stuff would break if the obsolete stuff were removed... so you'd have to confirm everything with mergemaster. Possibly this is too dangerous to be useful. But it would be nice to get rid of those really stale header files, etc. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On 2002-10-07 15:14, Archie Cobbs [EMAIL PROTECTED] wrote:
Anything that gets overwritten during the normal install process
is already taken care of. We're just trying to get rid of files
which are not installed by 'make installword' but used to be once.
I.e., if a file is not installed by 'make installworld' then by
definition it's not required for a correctly functioning system.
This might cause problems with ports that ``overwrite'' base-system
files. I hate ports the idea of ports writing anything outside of
${LOCALBASE}, but we already have some of those IIRC.
Giorgos.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Removing old binaries (was: Do we still need portmap(8)?)
On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? I don't think doing this by default is a good idea. Sometimes I like to preseve previous versions of things, knowing that they work. I'd prefer this as a job for mergemaster, asking you confirmation for each binary. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
From: David O'Brien: On Mon, Oct 07, 2002 at 08:39:06AM -0600, Seth Hieronymus wrote: afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 PHK had me dd if=/dev/afd0 of=/dev/null with no media in the drive. I get dd: /dev/afd0: Device busy, which is what the problem is. Some where in /sys/dev/ata is an EBUSY that should be ENXIO. If you can instrument at least atapi-all.c and atapi-fd.c and help track this down it would be most helpful. Thanks for the reply. Yes that makes sense. I'll see if I can look more at the code tonight. Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? What would you do about install -C? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Archie Cobbs wrote: You are right in that additional programs or custom modifications that depend on the obsolete stuff would break if the obsolete stuff were removed... so you'd have to confirm everything with mergemaster. Possibly this is too dangerous to be useful. But it would be nice to get rid of those really stale header files, etc. Yeah, that's why this discussion keeps coming up. People keep getting bit on the butt over it. 8-). You end up having to register source, target, build, and install relationships, as well as already installed relationships. It would really suck, too, when you had a third party package that got pulled into FreeBSD proper (e.g. first import of perl, or first import of expat2, where the built version conflicts with the installed version, but the installed version is not registered into the dependency tracking framework). It's an expensive problem to fix, and there's no way to fix it and make money from it (at least the way things stand), so there's no way to recover the expenses. Basically, you have to find someone willing to pay you to do the work, and willing to accept the risk of the code not making it back into the main FreeBSD tree because it steps on the toes of someone who could veto its inclusion. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Monday, 7 October 2002 at 17:44:42 -0700, Steve Kargl wrote: On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? What would you do about install -C? I think it confuses the issue rather than solving it. We're talking about removing binaries which are no longer needed, not replacing binaries that are needed. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? I don't think doing this by default is a good idea. Sometimes I like to preseve previous versions of things, knowing that they work. Nothing's stopping you saving them first.. I'd prefer this as a job for mergemaster, asking you confirmation for each binary. I'd much rather not have to do *anything* manually. That includes updating /etc, but that's a much larger can of worms. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2002-10-07 15:14, Archie Cobbs [EMAIL PROTECTED] wrote:
: Anything that gets overwritten during the normal install process
: is already taken care of. We're just trying to get rid of files
: which are not installed by 'make installword' but used to be once.
:
: I.e., if a file is not installed by 'make installworld' then by
: definition it's not required for a correctly functioning system.
:
: This might cause problems with ports that ``overwrite'' base-system
: files. I hate ports the idea of ports writing anything outside of
: ${LOCALBASE}, but we already have some of those IIRC.
Yes. Clearly, there are some files that should always be deleted
(stale binaries and header files), some files that should often be
deleted (those things replaced by ports under the same path, for
example), and some things we'd want to the user to removed (eg,
libfoo.so.N-1)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Tue, Oct 08, 2002 at 10:34:42AM +0930, Greg 'groggy' Lehey wrote: What would you do about install -C? I think it confuses the issue rather than solving it. We're talking about removing binaries which are no longer needed, not replacing binaries that are needed. install -C will not overwrite the file if it has not changed, thereby apparently breaking your remove everything older than this newly-installed file criterion. Kris msg44232/pgp0.pgp Description: PGP signature
Re: Removing old binaries
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : I think it confuses the issue rather than solving it. We're talking : about removing binaries which are no longer needed, not replacing : binaries that are needed. I'd be cool with a file that's a list of files that we had in the system in the past, but are safe to delete. NetBSD has a list of obsolete files, and it seems to work well there. We can just have a set of rules for when to add to this. List all the files that have had on a FreeBSD system since 2.0 or 3.0 to start. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? I don't think doing this by default is a good idea. Sometimes I like to preseve previous versions of things, knowing that they work. Nothing's stopping you saving them first.. In the same directory. I'd prefer this as a job for mergemaster, asking you confirmation for each binary. I'd much rather not have to do *anything* manually. That includes updating /etc, but that's a much larger can of worms. Well, then try fixing the tool so it's not as manual. I'd rather be presented with a list of things that have changed, and a way to select all or none, or enter a submenu for finer-grained control of what gets removed/updated (generalizing). I could imagine an option on mergemaster that removed old binaries without prompting. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Monday, 7 October 2002 at 21:18:10 -0400, Daniel Eischen wrote: On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? I don't think doing this by default is a good idea. Sometimes I like to preseve previous versions of things, knowing that they work. Nothing's stopping you saving them first.. In the same directory. Nothing's stopping you doing whatever you want, ultimately. I'm looking for the solution to the 99% case. I'd prefer this as a job for mergemaster, asking you confirmation for each binary. I'd much rather not have to do *anything* manually. That includes updating /etc, but that's a much larger can of worms. Well, then try fixing the tool so it's not as manual. Well, we used to have a tool which is automatic. I'd like to get back there. I'd rather be presented with a list of things that have changed, and a way to select all or none, or enter a submenu for finer-grained control of what gets removed/updated (generalizing). As I said, I'd rather not have to do *anything* manually. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
At 9:16 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002, M. Warner Losh wrote: I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I think we can greatly simplify things with one firm but relatively bearable rule: The directories /bin, /usr/bin, /sbin, /usr/sbin, insert others here are for the exclusive use of the system installer. Install other programs here at your peril: they will be overwritten on the next installation. There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? I hate this idea. installers should not run around removing files, especially files that they know nothing about. Overwriting files is one thing, explicitly removing files is something else. The idea of an mtree.obsolete is more reasonable, although I am not sure how workable it is. Obsolete, from when?. The list of obsolete files will be different for someone coming from 5.0-dp1 than it is for someone coming from 4.7-release. I could see this working ok, but I could also see it being a bit of a headache to maintain. This problem has been discussed in the past, and I think that what I'd like is something that I do in some situations. I have the 'install' script (my own...) keep track of what files were installed, and when. You could then ask the system which files are in a given directory, and did not get installed today (or some such question). I keep meaning to look at the base-system 'install' and see if there's some good way to add something to it for this idea. For builds of freebsd-current, every few weeks I do: mv /usr/include /usr/include.bak-mmdd mkdir /usr/include just before make installworld this gives me a pristine /usr/include, and does not remove any files. It's the idea of 'rm' commands which I find extremely unappealing, and rather user-hostile. If anything is added to clean out old files from /bin (etc), then I would really like to see it just *move* the files to some alternate directory structure, instead of going wild with rm commands. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Tue, Oct 08, 2002 at 10:34:42AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 17:44:42 -0700, Steve Kargl wrote: On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? What would you do about install -C? I think it confuses the issue rather than solving it. We're talking about removing binaries which are no longer needed, not replacing binaries that are needed. I understand what the topic is. I don't understand your comment, I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. install -C doesn't change the timestamp, so you'll have tons of files that are older than some file in the build tree. You don't blindly want to remove files and I doubt you want mergemaster to list possibly hundreds of files as removal candidates. So, yes, install -C confuses the issue :-) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
At 10:55 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 21:18:10 -0400, Daniel Eischen wrote: On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: I don't think doing this by default is a good idea. Sometimes I like to preseve previous versions of things, knowing that they work. Nothing's stopping you saving them first.. In the same directory. Nothing's stopping you doing whatever you want, ultimately. I'm looking for the solution to the 99% case. If we are talking about something which will be run, by default, for every person every time they do a 'make installworld', then I think that solution must be a more user-friendly. You're trying to solve a problem where you got an out-of-date man page. That is hardly a crisis. I'm trying to avoid the problem where 'installworld' blows away some important file on a user -- when it had absolutely no need to blow that file away. How about for each directory, if there are old files found in the directory then create a .OLDINSTALL sub-directory, and move the files into there (instead of removing them). And, of course, avoid descending into those .OLDINSTALL directories... Or, if there is a directory called '/buildbak', then move old files from (say) /usr/bin into /buildbak/usr/bin. Something like that. I just want something less destructive. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
On Monday, 7 October 2002 at 21:57:28 -0400, Garance A Drosihn wrote: At 10:55 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 21:18:10 -0400, Daniel Eischen wrote: On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote: I don't think doing this by default is a good idea. Sometimes I like to preseve previous versions of things, knowing that they work. Nothing's stopping you saving them first.. In the same directory. Nothing's stopping you doing whatever you want, ultimately. I'm looking for the solution to the 99% case. If we are talking about something which will be run, by default, for every person every time they do a 'make installworld', then I think that solution must be a more user-friendly. You're trying to solve a problem where you got an out-of-date man page. That is hardly a crisis. I'm trying to avoid the problem where 'installworld' blows away some important file on a user -- when it had absolutely no need to blow that file away. How about for each directory, if there are old files found in the directory then create a .OLDINSTALL sub-directory, and move the files into there (instead of removing them). And, of course, avoid descending into those .OLDINSTALL directories... That would be an option. But why do you need to put other files in these directories in the first place? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Monday, 7 October 2002 at 18:46:35 -0700, Steve Kargl wrote: On Tue, Oct 08, 2002 at 10:34:42AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 17:44:42 -0700, Steve Kargl wrote: On Tue, Oct 08, 2002 at 09:16:10AM +0930, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 11:20:56 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: There are then dozens of ways of finding the old files and removing them. I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Thoughts? What would you do about install -C? I think it confuses the issue rather than solving it. We're talking about removing binaries which are no longer needed, not replacing binaries that are needed. I understand what the topic is. I don't understand your comment, I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Ah, sorry, that might bear more explanation. install -C doesn't change the timestamp, so you'll have tons of files that are older than some file in the build tree. What does the last access timestamp look like after install -C? You don't blindly want to remove files and I doubt you want mergemaster to list possibly hundreds of files as removal candidates. So, yes, install -C confuses the issue :-) Indeed. What good reason do we have to use it on these directories? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dc and PCMCIA still panic
Today's kernel (cvs update-ed 10 minutes ago) keeps panicing when the dc-card is inserted :-/ The panic always happens in Fatal trap 12 [...] db trace pccard_scan_cis([data],0,0) at pccard_scan_cis+0x1a5 pccard_read_cis([data]) at pccard_read_cis+0xb5 [...] whether the card is inserted at run time, or the machine is booted with it inserted... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
I'd be inclined to just have a file with the a list and do something like the following at the end of Makefile.inc1, just after we do the sendmail install. .if (PURGE_OBSOELETE_FILES) @rm -fr `cat /etc/obsolete` .else if (SAVE_ONSOLETE_FILES) @mkdir /usr/obsolete @mv -f `cat /etc/obsolete` /usr/obsolete .endif Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc and PCMCIA still panic
In message: [EMAIL PROTECTED] Mikhail Teterin [EMAIL PROTECTED] writes: : Today's kernel (cvs update-ed 10 minutes ago) keeps panicing when the : dc-card is inserted :-/ : : The panic always happens in : : Fatal trap 12 : [...] : db trace : pccard_scan_cis([data],0,0) at pccard_scan_cis+0x1a5 : pccard_read_cis([data]) at pccard_read_cis+0xb5 : [...] : : whether the card is inserted at run time, or the machine is booted with : it inserted... That makes 0 sense. pccard_scan_cis is only called for pccards, but dc is a CardBus driver. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
At 11:29 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 21:57:28 -0400, Garance A Drosihn wrote: How about for each directory, if there are old files found in the directory then create a .OLDINSTALL sub-directory, and move the files into there (instead of removing them). And, of course, avoid descending into those .OLDINSTALL directories... That would be an option. But why do you need to put other files in these directories in the first place? What do you care? I bought the PC, freebsd did not. Maybe it is convenient for me to have a file there. Maybe I did it by mistake. Maybe it's a core file that landed there and I forgot to move it. Maybe you'll help me by removing it. Maybe you'll piss the hell out of me by destroying some important file that was never created by freebsd in the first place. Maybe I did an install -C because that was appropriate for *me*, in *my* situation. Maybe I installed some port with PREFIX=/. What do you care? What is GAINED by the freebsd project deciding that it has the right to go around destroying files on people's hard disks? I understand what is gained by moving known-obsolete files out of the way, but that does not justify going wild with rm commands just because freebsd wants to own /usr/bin and friends. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
At 11:31 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: install -C doesn't change the timestamp, so you'll have tons of files that are older than some file in the build tree. What does the last access timestamp look like after install -C? What does the last-access timestamp look like on an obsolete include file that you're picking by mistake? The main reason that obsolete files are a problem is that *something* is referencing them... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
On Monday, 7 October 2002 at 22:11:09 -0400, Garance A Drosihn wrote: At 11:29 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002 at 21:57:28 -0400, Garance A Drosihn wrote: How about for each directory, if there are old files found in the directory then create a .OLDINSTALL sub-directory, and move the files into there (instead of removing them). And, of course, avoid descending into those .OLDINSTALL directories... That would be an option. But why do you need to put other files in these directories in the first place? What do you care? I don't, up to the point where you ask the install process to respect your choice. I bought the PC, freebsd did not. Maybe it is convenient for me to have a file there. Maybe I did it by mistake. Maybe it's a core file that landed there and I forgot to move it. Maybe you'll help me by removing it. Maybe you'll piss the hell out of me by destroying some important file that was never created by freebsd in the first place. Maybe I did an install -C because that was appropriate for *me*, in *my* situation. Maybe I installed some port with PREFIX=/. What do you care? What is GAINED by the freebsd project deciding that it has the right to go around destroying files on people's hard disks? I thought I had explained that a while back. Consistency and repeatability. I understand what is gained by moving known-obsolete files out of the way, but that does not justify going wild with rm commands just because freebsd wants to own /usr/bin and friends. I would think that a NOCLEAN_OLD or some such option would probably be to accommodate you. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc and PCMCIA still panic
Even though it doesn't make sense, can you turn on the debugging information and run again? I use # Let's debug! hw.cbb.debug=1 hw.pccard.debug=1 hw.pccard.cis_debug=1 hw.cardbus.debug=1 hw.cardbus.cis_debug=1 Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Can't make depend or buildkernel for a custom kernel
Attached is my config file, here's the error I'm getting: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc - E CC=cc xargs mkdep -a -f .newdep -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/d ev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL - include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 If I use GENERIC, I can at least make depend. I'm also having problems with networking, seems like I can communicate with stuff listening on 127.0.0.1 just fine, but otherwise I can't connect to anything (traceroute works somewhat). Booting into an old (Sep 29) kernel works fine... actually I think this was broken within the past 7 days or so, I accidentally deleted my last working kernel. - alex machine i386 cpu I686_CPU ident ZIPPY_SMP maxusers0 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH options NFSCLIENT #Network Filesystem options NFSSERVER #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options PSEUDOFS options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev #options_KPOSIX_VERSION=199309L device random #entropy device #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device pci device fdc # Floppy drives # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapicam options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices options DDB options WITNESS options WITNESS_SKIPSPIN options INVARIANTS options INVARIANT_SUPPORT # SCSI peripherals device scbus # SCSI bus (required) device pass device cd device atkbdc # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbd device psm device vga device splash # splash screen/screen saver device sc # syscons is the default console driver, resembling an SCO console device npx # Floating point support - do not disable. device pmtimer # Add suspend/resume support for the i8254. #The orm device. This device gobbles up the Option ROMs in the ISA memory #I/O space. # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer # PCI Ethernet NICs. device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci# UHCI PCI-USB interface #device ohci# OHCI PCI-USB interface device usb
Re: Removing old binaries
At 11:45 AM +0930 10/8/02, Greg 'groggy' Lehey wrote: On Monday, 7 October 2002, Garance A Drosihn wrote: I bought the PC, freebsd did not. Maybe it is convenient for me to have a file there. Maybe I did it by mistake. Maybe it's a core file that landed there and I forgot to move it. Maybe you'll help me by removing it. Maybe you'll piss the hell out of me by destroying some important file that was never created by freebsd in the first place. Maybe I did an install -C because that was appropriate for *me*, in *my* situation. Maybe I installed some port with PREFIX=/. What do you care? What is GAINED by the freebsd project deciding that it has the right to go around destroying files on people's hard disks? I thought I had explained that a while back. Consistency and repeatability. Note that this is an argument to remove obsolete files. It is not an argument for destroying /usr/bin/garance-file. It is not an argument to destroy files which ARE current, but did not get changed due to an 'install -C'. It is not an argument to outlaw 'install -C', because *you* think that no one should need it. I understand what is gained by moving known-obsolete files out of the way, but that does not justify going wild with rm commands just because freebsd wants to own /usr/bin and friends. I would think that a NOCLEAN_OLD or some such option would probably be to accommodate you. If that is the default, sure. But if that was the default, then I don't see it doing much good. I would rather pick some solution that we could make the default, *and* not have to worry about it destroying some important file on some developer/user. I do understand the problem that we're hoping to solve here, and it seems to me we should pick a solution that developers don't have to protect themselves from. Please note that I'm not arguing this to protect some special quirk on my own personal systems. I am arguing it because I really think it is the wrong thing to do. Installers (IMO) just should not be removing files where they have no idea what the file is or how it got there. My own personal systems could live fine with the just remove it option. As I say, I'm already generating pristine /usr/include directories every month, so it is not like I personally need any special support. But someday that just remove it tactic will destroy some file that will greatly inconvenience some developer, and when that happens the developer is not going to be in the mood to hear some freebsd person say But why did you create that file there?, as if each user has to ask permission before creating files on hardware that they own. I remain perplexed as to why anyone would be fixated on the idea of destroying files on machines that the freebsd project does not own. Why must we pick the most user-hostile way to implement this? Well, I think I've reworded my concerns as many ways as I can think of, so I'll call it a night on this topic. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
I wrote: I understand what the topic is. I don't understand your comment, I'd be inclined just to remove all files in those directories which are older than some file in the build tree--*after* a successful installation. Ah, sorry, that might bear more explanation. install -C doesn't change the timestamp, so you'll have tons of files that are older than some file in the build tree. What does the last access timestamp look like after install -C? I'm not sure at this point in time (I haven't looked at the source in a year or so). I know install -C preserves the last modified and probably the created time. You don't blindly want to remove files and I doubt you want mergemaster to list possibly hundreds of files as removal candidates. So, yes, install -C confuses the issue :-) Indeed. What good reason do we have to use it on these directories? On slow hardware, install -C can significantly speed up a make installworld, because the installworld doesn't have to copy any files from /usr/obj to some destination. I'm beginning to think a mtree.obselete is the way to go. Each committer, who deletes something from the base system, should be required to update mtree.obselete. I think we should also add a make purifyworld or a new mergemaster option should invoke the mtree.obselete to clean the tree. I normally use touch(1) and find(1) to eliminate cruft. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
In message: [EMAIL PROTECTED] Steve Kargl [EMAIL PROTECTED] writes: : I'm beginning to think a mtree.obselete is the way to go. : Each committer, who deletes something from the base system, : should be required to update mtree.obselete. I think we : should also add a make purifyworld or a new mergemaster : option should invoke the mtree.obselete to clean the tree. I'm thinking that a list is the way to go. mtree doesn't know how to delete things in the list. We could hack it to so. Or we could just have a file that has a list of names and use the code that I posted before. It would be automatic if the user defines a variable. See my other posts for the simple code to do this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries (was: Do we still need portmap(8)?)
On Tue, Oct 08, 2002 at 10:35:39AM +0930, Greg 'groggy' Lehey wrote:
On Monday, 7 October 2002 at 20:07:37 -0400, Daniel Eischen wrote:
On Tue, 8 Oct 2002, Greg 'groggy' Lehey wrote:
I'd prefer this as a job for mergemaster, asking you confirmation
for each binary.
I'd much rather not have to do *anything* manually. That includes
updating /etc, but that's a much larger can of worms.
A year of so ago I made the following updates to mergemaster to solve
(some of) this problem for me. Its very simple and I'm sure its not for
everybody (and that it doesn't apply cleanly to the current mergemaster),
but I think the idea is sound.
This is the config that I use (for example):
ignore://etc/crontab/
ignore://etc/shells/
ignore://etc/inetd.conf/
ignore://etc/motd/
ignore://etc/sysctl.conf/
igrore://etc/syslog.conf
ignore://etc/passwd/
ignore://etc/master.passwd/
ignore://etc/group/
ignore://etc/printcap/
ignore://etc/ntp.conf/
ignore://etc/exports/
...
--
Chad David[EMAIL PROTECTED]
www.FreeBSD.org [EMAIL PROTECTED]
ACNS Inc. Calgary, Alberta Canada
--- /usr/home/davidc/dev/bsd/src/usr.sbin/mergemaster/mergemaster.shMon Aug 27
17:41:23 2001
+++ mergemaster Mon Sep 3 18:56:56 2001
@@ -15,8 +15,8 @@
display_usage () {
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
echo mergemaster version ${VERSION_NUMBER}
- echo 'Usage: mergemaster [-scrvahi] [-m /path]'
- echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]'
+ echo 'Usage: mergemaster [-scrvahiAX] [-m /path]'
+ echo ' [-t /path] [-d] [-u N] [-w N] [-D /path] [-C /path]'
echo Options:
echo -s Strict comparison (diff every pair of files)
echo -c Use context diff instead of unified diff
@@ -31,9 +31,49 @@
echo -u N Specify a numeric umask
echo -w N Specify a screen width in columns to sdiff
echo ' -D /path/directory Specify the destination directory to install files to'
+ echo -A Process files automatically from the mergemaster auto config file
+ echo -C /path/auto_config_file Specify location of auto config file to use
+ echo -X In the case of -A set the default to install. Normally the default is
+ignore
echo ''
}
+PROC_AUTO_CONF_FILE=/etc/mergemaster_auto.conf
+PROC_AUTO_RET_ERROR=-1
+PROC_AUTO_RET_DEFAULT=0
+PROC_AUTO_RET_IGNORE=1
+PROC_AUTO_RET_INSTALL=2
+PROC_AUTO_RET_DELETE=3
+
+proc_auto_check_file () {
+ F=$1
+
+ if [ ! -f ${PROC_AUTO_CONF_FILE} ] ; then
+return ${PROC_AUTO_RET_ERROR}
+ fi
+
+ FL=`grep \/${F}\/ ${PROC_AUTO_CONF_FILE}`
+
+ if [ ${#FL} -le 0 ] ; then
+return ${PROC_AUTO_RET_DEFAULT}
+ fi
+
+ ACT=`echo ${FL} | cut -f 1 -d :`
+ case ${ACT} in
+ignore | IGNORE)
+ return ${PROC_AUTO_RET_IGNORE}
+ ;;
+install | INSTALL)
+ return ${PROC_AUTO_RET_INSTALL}
+ ;;
+delete | DELETE)
+ return ${PROC_AUTO_RET_DELETE}
+ ;;
+*)
+ return ${PROC_AUTO_RET_DEFAULT}
+ ;;
+ esac
+}
+
display_help () {
echo * To specify a directory other than /var/tmp/temproot for the
echo temporary root environment, use -t /path/to/temp/root
@@ -226,8 +266,20 @@
# Check the command line options
#
-while getopts :ascrvhim:t:du:w:D: COMMAND_LINE_ARGUMENT ; do
+while getopts :ascrvhim:t:du:w:D:AC:X COMMAND_LINE_ARGUMENT ; do
case ${COMMAND_LINE_ARGUMENT} in
+ A)
+PROC_AUTO=yes
+AUTO_RUN=yes
+ AUTO_INSTALL=yes
+unset VERBOSE
+ ;;
+ C)
+PROC_AUTO_CONF_FILE=${OPTARG}
+;;
+ X)
+PROC_AUTO_DEFAULT_TO_INSTALL=yes
+;;
s)
STRICT=yes
;;
@@ -673,7 +725,7 @@
unset DONT_INSTALL
;;
esac
- else # File matched -x
+ else # File matched -x
case ${1#.} in
/dev/MAKEDEV)
NEED_MAKEDEV=yes
@@ -699,6 +751,44 @@
# check the scripts in ./dev, as we'd like (assuming no devfs of course).
#
for COMPFILE in `find . -type f -size +0`; do
+
+ # If set to yes, then ignore normal processing XXXCPD
+ if [ x${PROC_AUTO} = xyes ] ; then
+proc_auto_check_file ${COMPFILE#.}
+_PROC_AUTO_CHECK_RET=$?
+
+if [ ${_PROC_AUTO_CHECK_RET} -eq ${PROC_AUTO_RET_ERROR} ] ; then
+ echo proc_auto_check_file failed
+ exit 1
+elif [ ${_PROC_AUTO_CHECK_RET} -eq ${PROC_AUTO_RET_DEFAULT} ] ; then
+ echo proc_auto_ret_default for ${COMPFILE}
+ if [ x${PROC_AUTO_DEFAULT_TO_INSTALL} = xyes ] ; then
+ echo default to install is set to yes
+if ! mm_install ${COMPFILE} ; then
+ echo mm_install failed
+ exit 1
+fi
+ else
+continue
+ fi
+elif [ ${_PROC_AUTO_CHECK_RET} -eq ${PROC_AUTO_RET_INSTALL} ] ; then
+ echo proc_auto_ret_install for ${COMPFILE}
+ if ! mm_install ${COMPFILE} ; then
+echo mm_install failed
+exit 1
+ fi
+elif [ ${_PROC_AUTO_CHECK_RET} -eq ${PROC_AUTO_RET_IGNORE} ] ; then
+ echo proc_auto_ret_ignore for ${COMPFILE}
+ continue
+elif [ ${_PROC_AUTO_CHECK_RET} -eq
Re: Can't make depend or buildkernel for a custom kernel
: cc: Internal error: Segmentation fault (program cpp0) http://people.freebsd.org/~kan/gcc-cpp.diff Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc and PCMCIA still panic
Even though it doesn't make sense, can you turn on the debugging information and run again? I use # Let's debug! hw.cbb.debug=1 hw.pccard.debug=1 hw.pccard.cis_debug=1 hw.cardbus.debug=1 hw.cardbus.cis_debug=1 Actually, I lied... It is a Xircom RealPort Ethernet 10/100 + Modem 56 REM56G -- the xe card. Rebooting now to try the switches above. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc and PCMCIA still panic
In message: [EMAIL PROTECTED] Mikhail Teterin [EMAIL PROTECTED] writes: : Even though it doesn't make sense, can you turn on the debugging : information and run again? I use : : # Let's debug! : hw.cbb.debug=1 : hw.pccard.debug=1 : hw.pccard.cis_debug=1 : hw.cardbus.debug=1 : hw.cardbus.cis_debug=1 : : Actually, I lied... It is a Xircom RealPort Ethernet 10/100 + Modem 56 : REM56G -- the xe card. Oh, that's different This is with my changes to pccard_cis.c? I've never been able to get my IBM version of this card to work at all... Do you get screen fulls of CIS parsing before the fall? That's what I see both before and after that change. I think that something strange is going on with a few cards that the code doesn't handle quite right. I have maybe 4 of them at the moment. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
On Mon, Oct 07, 2002 at 09:24:44PM -0600, M. Warner Losh wrote: : cc: Internal error: Segmentation fault (program cpp0) http://people.freebsd.org/~kan/gcc-cpp.diff Cool. make depend works now, let's see if the resulting kernel does. :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
In message: [EMAIL PROTECTED] Alex Zepeda [EMAIL PROTECTED] writes: : http://people.freebsd.org/~kan/gcc-cpp.diff : : Cool. make depend works now, let's see if the resulting kernel does. :) I hit this same problem. Robert pointed me at this patch and I've booted 10 kernels built since then. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
On Mon, Oct 07, 2002 at 10:29:34PM -0600, M. Warner Losh wrote: I hit this same problem. Robert pointed me at this patch and I've booted 10 kernels built since then. Burried in my original post: I'm also having problems with networking, seems like I can communicate with stuff listening on 127.0.0.1 just fine, but otherwise I can't connect to anything (traceroute works somewhat). Booting into an old (Sep 29) kernel works fine... actually I think this was broken within the past 7 days or so, I accidentally deleted my last working kernel. But yeah, I expect it will boot just fine. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
Alex Zepeda wrote: I'm also having problems with networking, seems like I can communicate with stuff listening on 127.0.0.1 just fine, but otherwise I can't connect to anything (traceroute works somewhat). Booting into an old (Sep 29) kernel works fine... actually I think this was broken within the past 7 days or so, I accidentally deleted my last working kernel. I've noticed netmask problems in -current. If you set it to an larger boundary, it appears to be OK (e.g. I has to set 0x for 192.168.0.X to work). -- Terry 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 -- stage 4: make dependencies -- stage 4: building everything.. -- === sys/boot/i386/boot2 kernel: ver=1.01 size=780 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1484 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e04 text=200 data=1c04 org=0 entry=0 -4 bytes available *** Error code 1 Stop in /local0/scratch/des/src/sys/boot/i386/boot2. *** Error code 1 Stop in /local0/scratch/des/src/sys/boot/i386. *** Error code 1 Stop in /local0/scratch/des/src/sys/boot. *** Error code 1 Stop in /local0/scratch/des/src/sys. *** 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
