Re: Trouble Building CURRENT on STABLE, cpp seg. fault
Giorgos Keramidas wrote: On 2002-09-21 23:53, Crist J. Clark [EMAIL PROTECTED] wrote: I've been unable to build CURRENT on STABLE for a few days. I made sure to bring STABLE up to date. Is this just me? Is there a problem with building CURRENT on STABLE at the moment? It isn't just you. The same error stopped my build of current 2-3 days ago on 4.6-RELEASE. if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep 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 -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev -I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -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 This is not just a problem with stable. I had the same problem building a kernel with Sept. 22, 7:30AM EDT cvsup of current source. My machine is running current from about a month ago. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: oops: panic: bremfree: bp 0xc4206410 not locked
I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Jim Bloom [EMAIL PROTECTED] Alex Zepeda wrote: I got this while the system was swapping quite a bit (silly Gtk+ newsreader + supernews's huge retention == lots of memory used). FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 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 0xc4206410 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4206410 not locked cpuid = 0; lapic.id = Uptime: 1h20m25s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112[CTRL-C to abort] --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, len=14) at ../../../kern/vfs_cluster.c:801 #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) at ../../../kern/vfs_bio.c:1620 #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, td=0xc03ed9c0) at vnode_if.h:545 #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) at ../../../kern/vfs_syscalls.c:129 #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) at ../../../vm/uma_dbg.c:186 #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 zone_drain) at ../../../vm/uma_core.c:1167 #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #18 0xc0212330 in fork_exit (callout=0xc02fe784 vm_pageout, arg=0x0, frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 (kgdb) quit 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: PC Card hang
I haven't built a new kernel since I had got it working (by fetching the version before the commit). I haven't noticed any commits that might have been related to fixing this but I'm a couple weeks behind on reading cvs-all. Jim Bloom M. Warner Losh wrote: From: Jim Bloom [EMAIL PROTECTED] Subject: PC Card hang Date: Tue, 27 Nov 2001 19:26:04 -0500 : My laptop is hanging when I boot it after this commit. The system hangs : when pccardd is started. If no cards are installed, the boot proceeds : without a problem and the system hangs when the first card is inserted. ... : Modified files: : sys/pccard i82365.h pcic.c pcic_isa.c pcic_pci.c : Log: : o Try to do 3.3V support better for the 6722 and 6729/30. : o Bite the bullet and create controller types for the 6729 and also ... : Revision ChangesPath : 1.23 +18 -5 src/sys/pccard/i82365.h : 1.169 +32 -14src/sys/pccard/pcic.c : 1.23 +3 -3 src/sys/pccard/pcic_isa.c : 1.106 +5 -5 src/sys/pccard/pcic_pci.c Did this get resolved? Warner 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: PC Card hang
The chipset is reported as a 6722 by the newer kernels that do not work. I will forward the earlier e-mails to you. Jim Bloom M. Warner Losh wrote: OK. I'll keep that in mind. I'm in a bit if a time crunch until after the first of the year. I can't seem to find where you told me which bridge chipset you were using. Presumably it is a 6729/6730? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PC Card hang
My laptop is hanging when I boot it after this commit. The system hangs when pccardd is started. If no cards are installed, the boot proceeds without a problem and the system hangs when the first card is inserted. I have attached my kernel configuration and dmesg output from a kernel checked out right before this commit. Please let me know if I can provide any further information or assistance. Thanks for you help Jim Bloom [EMAIL PROTECTED] Modified files: sys/pccard i82365.h pcic.c pcic_isa.c pcic_pci.c Log: o Try to do 3.3V support better for the 6722 and 6729/30. o Bite the bullet and create controller types for the 6729 and also for the 673x. Rename the 672x to 6722. o Define minimal extended register info (just register 0xa for reading VS[12]). # I think the last version may have broken 673x controllers, but this should # fix them. Tested on the 6722, but not the 6729. Ideas from: Chiharu Shibata-san's article in bsd-nomads:15866 Revision ChangesPath 1.23 +18 -5 src/sys/pccard/i82365.h 1.169 +32 -14src/sys/pccard/pcic.c 1.23 +3 -3 src/sys/pccard/pcic_isa.c 1.106 +5 -5 src/sys/pccard/pcic_pci.c machine i386 cpu I486_CPU cpu I586_CPU ident LAPTOP maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INVARIANTS options INVARIANT_SUPPORT # options MUTEX_DEBUG options WITNESS options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options FFS #Berkeley Fast Filesystem options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console #optionsUSERCONFIG #boot -c editor 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 extentions options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options IPFIREWALL #firewall options IPDIVERT#divert sockets options DDB #kernel debugger # Obsolete option # options MD_NSECT=1 device isa # Add PCI to work around broken ATA driver # devicepci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc device atkbd device psm device vga # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Power management support (see LINT for more options) device apm # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # ISA Ethernet NICs. device ed device miibus # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device sl 1 # Kernel SLIP device ppp 1 # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks device pmtimer # Adjust system timer at wakeup time device random # for IPv6 device gif #IPv6 and IPv4 tunneling device faith #for IPv6 and IPv4 translation # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf
Re: PC Card hang
A later kernel (possibly today's source) say that it is a 6722 instead of a 672x. Other changes in the dmesg output (copied by hand since the machine does not survive) are : pcic0: Autodected 3.3V card (once per card) pcic0: reset 1 int is 0 stat is cc (once per card, stat was df or ff before) pcic0: reset 2 int is 60 stat is cc pcic0: reset 3 int is 60 stat is cc The machine is an old AST Ascentia 810N. Jim Warner Losh wrote: In message [EMAIL PROTECTED] Jim Bloom writes: : I have attached my kernel configuration and dmesg output from a kernel : checked out right before this commit. Please let me know if I can : provide any further information or assistance. What does one from right after say? It looks like you have a CLPD6722 in your machine... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
page fault in mpu.c
I finally tracked down the page fault I was seeing while probing the mpu.
The mutex was not being initialized before it was used. I have included a
patch below which fixes the problem. Will someone please review the style
and commit the fix.
Thanks.
Jim Bloom
[EMAIL PROTECTED]
Index: mpu.c
===
RCS file: /users/ncvs/src/sys/dev/sound/isa/mpu.c,v
retrieving revision 1.5
diff -u -r1.5 mpu.c
--- mpu.c 2001/03/14 07:29:46 1.5
+++ mpu.c 2001/03/27 02:20:29
@@ -358,6 +358,8 @@
DEB(printf("mpu: attaching.\n"));
+ mtx_init(scp-mtx, "mpumid", MTX_DEF);
+
/* Allocate the resources, switch to uart mode. */
if (mpu_allocres(scp, dev) || mpu_uartmode(scp)) {
mpu_releaseres(scp, dev);
@@ -368,7 +370,6 @@
/* Fill the softc. */
scp-dev = dev;
- mtx_init(scp-mtx, "mpumid", MTX_DEF);
scp-devinfo = devinfo = create_mididev_info_unit(MDT_MIDI, mpu_op_desc,
midisynth_op_desc);
/* Fill the midi info. */
@@ -751,6 +752,7 @@
bus_release_resource(dev, SYS_RES_IOPORT, scp-io_rid, scp-io);
scp-io = NULL;
}
+ mtx_destroy(scp-mtx);
}
static device_method_t mpu_methods[] = {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
I get a slightly different backtrace, but was able to use my palm pilot as the
serial console. I have had this same problem for quit a while (about a month).
I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last
cvsup was within the past 24 hours and the kernel was built in a clean
directory.
I can try to get more information if necessary.
Jim Bloom
[EMAIL PROTECTED]
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1a0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c8006
stack pointer = 0x10:0xc04e66dc
frame pointer = 0x10:0xc04e66db
trace
_mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a
mpu_uartmode(c0ecda00) at mpu_uartmode+0x63
mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25
mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19
device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a
bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at
bus_generic_attach+0x16
sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc
device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at
device_probe_and_attach+0x9a
isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at
isa_probe_children+0x143
configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39
mi_startup() at mi_startup+0x68
begin() at begin+0x29
db panic
panic: from debugger
Debugger("panic")
Stopped at _mtx_lock_sleep+0x29a: movl0x1a0(%edx),%eax
Szilveszter Adam wrote:
Hello folks,
I have tried it with today's -CURRENT, and as soon as I try to boot a
kernel with the options (this has occured also earlier but wanted to make
sure that I try today's sources first)
device midi
device seq
(my sound card is a ISAPnP SB 64 AWE)
I use device sbc too.
the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's
fixes, and yet this still happens. I do not have a serial console, so here
a short trace output transcribed:
_mtx_lock_sleep
mpu_uartmode
mpu_attach
mprobe_attach
device_probe_and_attach
bus_generic_attach
sbc_attach
device_probe_and_attach
isa_probe_children
configure
mi_startup()
begin()
At the point of panic not even the swap partition is available yet so the
machine does not dump. How can I force it?
I would like to offer any and all help to anyone wanting to debug this; I
can reproduce the problem at will and luckily no FS corruption occurs
because the panic is so early on boot.:-)
Of course, as soon as I omit the midi part, the kernel boots fine, and the
sound card works too.
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
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
kernel link problems with ata driver
For the past couple weeks I have been unable to build a kernel for my laptop. I keep getting undefined symbols. The problem started with the split of the ata driver by different bus attachments. My laptop only has ISA and not PCI so I don't include PCI in the kernel config file. The errors and kernel configuration are included below. Jim Bloom [EMAIL PROTECTED] linking kernel ata-all.o: In function `ata_service': ata-all.o(.text+0x1332): undefined reference to `ata_dmastatus' ata-all.o: In function `ata_change_mode': ata-all.o(.text+0x1dc1): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_attach': ata-disk.o(.text+0x36c): undefined reference to `ata_dmainit' ata-disk.o(.text+0x39d): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_start': ata-disk.o(.text+0xa14): undefined reference to `ata_dmaalloc' ata-disk.o: In function `ad_transfer': ata-disk.o(.text+0xbf4): undefined reference to `ata_dmasetup' ata-disk.o(.text+0xd14): undefined reference to `ata_dmastart' ata-disk.o: In function `ad_interrupt': ata-disk.o(.text+0xf13): undefined reference to `ata_dmadone' ata-disk.o(.text+0x1029): undefined reference to `ata_dmainit' ata-disk.o(.text+0x1092): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_service': ata-disk.o(.text+0x1518): undefined reference to `ata_dmastart' ata-disk.o: In function `ad_timeout': ata-disk.o(.text+0x177f): undefined reference to `ata_dmadone' ata-disk.o(.text+0x17b8): undefined reference to `ata_dmainit' ata-disk.o: In function `ad_reinit': ata-disk.o(.text+0x18fe): undefined reference to `ata_dmainit' ata-disk.o(.text+0x1929): undefined reference to `ata_dmainit' *** Error code 1 machine i386 cpu I486_CPU cpu I586_CPU ident LAPTOP maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INVARIANTS options INVARIANT_SUPPORT # options MUTEX_DEBUG options WITNESS options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options FFS #Berkeley Fast Filesystem options MFS #Memory Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor 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 extentions options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options IPFIREWALL #firewall options IPDIVERT#divert sockets options DDB #kernel debugger # Obsolete option # options MD_NSECT=1 device isa # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc device atkbd device psm device vga # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Power management support (see LINT for more options) device apm # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # ISA Ethernet NICs. device ed device miibus # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device sl 1 # Kernel SLIP device ppp 1 # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc
Re: panic: resource_list_alloc
Try "make reinstall". I have been doing quite a bit of this since my kernel panics before it ever gets all the way up. The last good kernel I have is about a month old. Actually, I moved /boot/kernel.old to another name in case I accidentally did an install instead of a reinstall. I don't want to leave my machine unable to boot. Jim Bloom [EMAIL PROTECTED] The Hermit Hacker wrote: doing so right now ... one quick/stupid question ... how does one 'reinstall' a new kernel so that you don't lose the /boot/kernel.old (aka backup that worked)? I've been moving files around before installing the rebuilt kernel, but that doesn't sound very efficient ... :) thanks .. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build failure
Did you add "device miibus" to you kernel configuration? Jim Bloom [EMAIL PROTECTED] Paul Allenby wrote: Hi all From sources cvsup'd about an hour ago, "make depend" complains: ../../dev/ed/if_ed_pccard.c:58: miibus_if.h: No such file or directory and fails. This is after deleting the old kernel build dir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL ASM patch
I do plenty of build once and run on multiple machines. My biggest machine is a PII 40MHZ where I compile the world and kernels for a 486 laptop and P-60 Router/Firewall. I would not really want to compile the world on these slower machines over nfs. For my case, I guess I could rebuild only the ssl library for each machine properly tuned. For my small collection of machines, that wouldn't be too bad, but for larger sites it would be a problem. I could probably find some way to compile multiple version with buildworld and figure out the correct one to install with installworld. Jim Bloom [EMAIL PROTECTED] Peter Jeremy wrote: IMHO, the main market for this feature would be people who just do binary installs - if you're doing a buildworld, you can tune to your hardware[1]. If we wanted to just speed up OpenSSL on binary installs, we could have processor-optimised variants of libssl.* available as packages (tick the box that suits your processor if you want the optimised library). [1] I don't think there's a lot of `build once, install on lots of different hardware', though I could be wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] PS: Here is the original message. It was cut and pasted from the logs since your message is sitting in another OS on a dual boot machine. On 06-Feb-01 Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here are the registers (subject to typing errors): cs 0xc2fb0008 ds 0xa10 es0x10 fs0x18 ss0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi 0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] Hm, can you show the registers? I wonder if we are somehow running a process that isn't fully created yet. Hmm, that shouldn't be a problem looking at fork1().. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. Jim Bloom [EMAIL PROTECTED] P.S. I am hitting the same problem Robert Watson mentioned. I don't have room for three kernels on the machine. John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Here are the registers (subject to typing errors): cs0xc2fb0008 ds 0xa10 es 0x10 fs 0x18 ss 0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx 0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] Erm, this doesn't look good: movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */ ltr %si #define GPROC0_SEL 4 /* Task state process slot zero and up */ Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is screwed up, unless something is overwriting your code segment. Can you panic it and do an x/i of sw1b+0x72? It should look something like this: 121: be 20 00 00 00 mov$0x20,%esi 126: 0f 00 deltr%si To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. Do you have any other ideas on things that I can try to diagnose this problem? Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem building md module
While trying to build a new kernel today, I received errors relating to
vnode_if.h not existing. I have put the patch below which fixed the
problem for me. (Sorry if the patch does not apply because of cut and
paste errors, but it may easily be hand editted.)
Jim Bloom
[EMAIL PROTECTED]
Index: Makefile
===
RCS file: /users/ncvs/src/sys/modules/md/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile2000/09/02 19:17:10 1.7
+++ Makefile2000/12/31 18:35:36
@@ -2,7 +2,7 @@
.PATH: ${.CURDIR}/../../dev/md
KMOD= md
-SRCS= md.c opt_mfs.h opt_md.h
+SRCS= md.c opt_mfs.h opt_md.h vnode_if.h
NOMAN=
.include bsd.kmod.mk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: AWE-64 no longer detected...
Mine seems to be detected just fine with a CVSUP on Sat Nov 11, 2000 at around 22:00 EST. The only error I get whiel trying to detect the card is: pci0: unknown card (vendor=0x11d1, dev=0x01f7) at 10.0 irq 9 I might submit a fix for this error at some point, but it doesn't affect anything. Jim Bloom [EMAIL PROTECTED] Glendon Gross wrote: Since my last cvsup, my Soundblaster AWE-64 card is no longer detected. unknown: Audio can't assign resources unknown: Game can't assign resources unknown0: WaveTable at port 0x620-0x623 on isa0 Has anyone else seen this problem? Below is the full dmesg output. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
There is a minor typo in the URL. The patches are at: http://people.freebsd.org/~imp/if_vx.patch Jim Bloom [EMAIL PROTECTED] Warner Losh wrote: Someone (I can't find who in my records, please let me know if it was you so I can credit you in the commit message) sent out patches to make the vx driver not use the pci compat shims. I just found it in my home directory, applied it, tweaked things very minorly and it builds and boots. Trouble is, I don't have a vortex to test with. It also appears that there is no driver maintainer at this time, so I thought I'd send it here. Please review my patches at http://people/.freebsd.org/~imp/if_vx.patch I'd like to commit this in a few days. If you have a vortex board, please give it a spin with these patches and let me know if there are any problems. If you have any problems with the patches, let me know. I'll commit this next weekend or so if there are no outstanding issues by that time. I think this means lnc is the last one in the tree, but I could be wrong about that. I didn't do an actual grep... Warner 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: Another broken buildworld
This is a pain. cvsup3 is the closest mirror to me. The only file I could find missing on cvsup3 was rsa_eay.c. Garrett, now that RSA has released the patent, would you be willing to add this file to the mirror on cvsup3? Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: On Sun, 10 Sep 2000, Eric Hedberg wrote: OK, fresh cvsup (blew away the old /usr/src, slurped down a new one this afternoon). Don't cvsup from cvsup3, it doesnt carry a full crypto mirror. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in current?
Fixed with revision 1.14 sys/kern/kern_event.c. Update your kernel sources and the problem should go away. Jim Bloom [EMAIL PROTECTED] "Damon M. Conway" wrote: Damon Hammis wrote: Has anyone else stumbled across this bug in 5.0-CURRENT? Whenever I try to do a tail -f on a text file the system locks up and requires a hard reboot. Anyone else see anything similar? yes, there is a long discussion on -current about it right now. damon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: keyboard problems with X
To resolve the problem with tail, rebuild your kernel with revision 1.11 of sys/kern/kern_event.c. 1.12 which was designed to make the kevent system restartable seems to keep the process from ever receiving the interrupt. I don't have a solution which solves both problems yet. Jim Bloom [EMAIL PROTECTED] Kenneth Wayne Culver wrote: I have, like when I'm running tail on something, and then I try to ctrl-c out of it, the whole console locks solid, and I have to reboot. (although if I was connected to an ethernet, I think I could probably ssh in and reboot.) Also, as an unrelated problem in -CURRENT, I'm experiencing the lockmgr problems that were reported earlier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_event.c
I didn't have much time for testing, but backing out this change fixes the problem tail. For some reason, the signal never gets delivered to the process. The manual page states that the kevent processing is lower priority than signal handling and that the signal will get processed as normal before the event will will be logged. In fact, I witnessed a case where a SIGKILL would not kill the process after a SIGINT. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: I am having problems with "tail -f" hanging the machine. I don't know if this change is related, but I suspect that it might be. I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I interrupted the tail, the machine hung. I then tried to figure out what was causing the problem. Eventually, I tracked the problem down to tail. The machine would respond to pings, but the keyboard was useless. It would not shutdown as well. One test I tried was to run tail -f under truss. This actually kept the machine somewhat usable. Top showed truss using 75% of the CPU and tail using the other 25%. System time was running over 80%. Truss reported that tail kept receiving the signal (indefinitely as far as I could tell) at a high rate of speed. I tried to get a kernel core dump several times by breaking into ddb, but I never had any luck. Here is the backtrace copied by hand: vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 Xinit0x80_syscall() at Xint0x80_syscall+0x25 My kernel and source tree both date from 20:00-22:00 EDT on July 28. I found the problem to be quite repeatable by simply going "tail -f file" (the file does not need to change) and then hitting an interrupt on the keyboard. Let me know if I can be of any assistance in tracking this problem down. I might try to spend some time tomorrow figuring out what is happening. Jim Bloom [EMAIL PROTECTED] Jonathan Lemon wrote: jlemon 2000/07/27 16:06:15 PDT Modified files: sys/kern kern_event.c Log: Have kevent() automatically restart if interrupted by a signal. If this is not desired, then the user can register an EV_SIGNAL filter to explicitly catch a signal event. Change requested by: jayanth, ps, peter "Why is kevent non-restartable after a signal?" Revision ChangesPath 1.12 +3 -6 src/sys/kern/kern_event.c 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: cvs commit: src/sys/kern kern_event.c
I did a little more testing of this problem just now. A SIGKILL does not kill the process but will lock up the machine. Truss reports the SIGKILL being continuously sent to the process. If I break into DDB, and then panic, I get a panic "lockmgr: pid XXX, not exclusive lock holder 0 unlocking". The pid is for the tail command. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: I didn't have much time for testing, but backing out this change fixes the problem tail. For some reason, the signal never gets delivered to the process. The manual page states that the kevent processing is lower priority than signal handling and that the signal will get processed as normal before the event will will be logged. In fact, I witnessed a case where a SIGKILL would not kill the process after a SIGINT. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: I am having problems with "tail -f" hanging the machine. I don't know if this change is related, but I suspect that it might be. I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I interrupted the tail, the machine hung. I then tried to figure out what was causing the problem. Eventually, I tracked the problem down to tail. The machine would respond to pings, but the keyboard was useless. It would not shutdown as well. One test I tried was to run tail -f under truss. This actually kept the machine somewhat usable. Top showed truss using 75% of the CPU and tail using the other 25%. System time was running over 80%. Truss reported that tail kept receiving the signal (indefinitely as far as I could tell) at a high rate of speed. I tried to get a kernel core dump several times by breaking into ddb, but I never had any luck. Here is the backtrace copied by hand: vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 Xinit0x80_syscall() at Xint0x80_syscall+0x25 My kernel and source tree both date from 20:00-22:00 EDT on July 28. I found the problem to be quite repeatable by simply going "tail -f file" (the file does not need to change) and then hitting an interrupt on the keyboard. Let me know if I can be of any assistance in tracking this problem down. I might try to spend some time tomorrow figuring out what is happening. Jim Bloom [EMAIL PROTECTED] Jonathan Lemon wrote: jlemon 2000/07/27 16:06:15 PDT Modified files: sys/kern kern_event.c Log: Have kevent() automatically restart if interrupted by a signal. If this is not desired, then the user can register an EV_SIGNAL filter to explicitly catch a signal event. Change requested by: jayanth, ps, peter "Why is kevent non-restartable after a signal?" Revision ChangesPath 1.12 +3 -6 src/sys/kern/kern_event.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_event.c
I am having problems with "tail -f" hanging the machine. I don't know if this change is related, but I suspect that it might be. I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I interrupted the tail, the machine hung. I then tried to figure out what was causing the problem. Eventually, I tracked the problem down to tail. The machine would respond to pings, but the keyboard was useless. It would not shutdown as well. One test I tried was to run tail -f under truss. This actually kept the machine somewhat usable. Top showed truss using 75% of the CPU and tail using the other 25%. System time was running over 80%. Truss reported that tail kept receiving the signal (indefinitely as far as I could tell) at a high rate of speed. I tried to get a kernel core dump several times by breaking into ddb, but I never had any luck. Here is the backtrace copied by hand: vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 Xinit0x80_syscall() at Xint0x80_syscall+0x25 My kernel and source tree both date from 20:00-22:00 EDT on July 28. I found the problem to be quite repeatable by simply going "tail -f file" (the file does not need to change) and then hitting an interrupt on the keyboard. Let me know if I can be of any assistance in tracking this problem down. I might try to spend some time tomorrow figuring out what is happening. Jim Bloom [EMAIL PROTECTED] Jonathan Lemon wrote: jlemon 2000/07/27 16:06:15 PDT Modified files: sys/kern kern_event.c Log: Have kevent() automatically restart if interrupted by a signal. If this is not desired, then the user can register an EV_SIGNAL filter to explicitly catch a signal event. Change requested by: jayanth, ps, peter "Why is kevent non-restartable after a signal?" Revision ChangesPath 1.12 +3 -6 src/sys/kern/kern_event.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems building kernel with IPSEC_DEBUG
While compiling a kernel with recent code (cvsup 22:30 -0400 July 6), I had some undefined symbols. I traced the symbols to netkey/key_debug.c and found that it did not test IPSEC_DEBUG correctly. I have attached a patch below. Jim Bloom [EMAIL PROTECTED] Index: netkey/key_debug.c === RCS file: /users/ncvs/src/sys/netkey/key_debug.c,v retrieving revision 1.11 diff -u -r1.11 key_debug.c --- netkey/key_debug.c 2000/07/04 16:35:14 1.11 +++ netkey/key_debug.c 2000/07/07 03:26:30 @@ -33,6 +33,7 @@ #ifdef _KERNEL #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_ipsec.h" #endif #include sys/types.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
The RCS info stored in the binaries is insufficient for this purpose. There is no record of the versions of all included files. Changes to constants and/or macros would not be identifiable. Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: On Tue, 25 Apr 2000, Brandon D. Valentine wrote: The only way something like this is feasible is if the binaries themselves contain information about what version they are. In other words some sort of a header in the binary which contains the RCS version number the binary was compiled from so that whatever method you were You've never run ident(1), right? :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA library problems
Dirk Roehrdanz wrote:
Thanks for the modification.
I have replaced the "[]" with "{}" . A run of "make buildworld" with
the patch finished without errors.
Sorry about that. I did it quickly and the font I was using has the characters
looking identical. Time to change fonts :-)
The output of objdump --private-headers on the created librsaINTL.so.1
libs under /usr/obj contains now the line "NEEDED libcrypto.so.1".
Apache-modssl works now with encryption!
Good news. I was sure that would fix the problem.
Should I file a pr with the patch ?
If you like. Hopefully someone will pick it up from the list sooner and commit
the patch. send-pr is the official channel for reporting bugs.
Jim Bloom
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RSA library problems
A similar patch was added for the USA version of RSA for the same basic reason. Your patch is almost correct. It should add the line: LDADD+= -L$[.OBJDIR]/../libcrypto -lcrypto Your version would reference the system crypto library and not the one being built as part of buildworld. Jim Bloom [EMAIL PROTECTED] Dirk Roehrdanz wrote: I had the same problem. "BN_mod_exp_mont" is in libcrypto,but isn't visible from librsaINTL.so because libcrypto is loaded in conjunction with the load of /usr/local/libexec/apache/libssl.so via dlopen() . The man page to dlopen states " The symbols exported by objects added to the address space by dlopen() can be accessed only through calls to dlsym()". I have solved the problem with the attached patch. It adds libcrypto to the list of linked libs. Maybe there is a better solution,who knows ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
Upgrade sys/vm/swap_pager.c to the current version. There was a bug there which
has been fixed.
Jim Bloom
[EMAIL PROTECTED]
FreeBSD mailing list wrote:
/var/log/messages indicates:
Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
I reproduced the problem and have attached a patch. It was the exact same problem as in swap_pager.c (assuming B_WRITE was 0). Hopefully phk will commit this fix shortly. Jim Bloom [EMAIL PROTECTED] \ FreeBSD mailing list wrote: I cvsup'd once more this morning... Nothing significant has changed since the last one. For reference: ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c * $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $ Nonetheless, I built a new kernel using "config -r". No change in floppy operation. Index: sys/isa/fd.c === RCS file: /users/ncvs/src/sys/isa/fd.c,v retrieving revision 1.179 diff -u -r1.179 fd.c --- sys/isa/fd.c2000/03/20 11:28:39 1.179 +++ sys/isa/fd.c2000/03/24 20:20:53 @@ -2228,6 +2228,7 @@ BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); bp-b_flags = B_PHYS | B_FORMAT; + bp-b_iocmd = BIO_WRITE; /* * calculate a fake blkno, so fdstrategy() would initiate a
Re: fd0: Debugger(d_iocmd botch) called.
FreeBSD mailing list wrote: This patch does indeed fix the writing of floppies. However, fdformat(1) still fails as follows: That is very strange. My patch only applies to formatting floppies. It did not touch any routine used in writing a floppy. I have no idea at this time what is causing your other problems. I am unable to write to a floppy at this time. I'm not seeing any errors, but nothings is getting written. Jim Bloom [EMAIL PROTECTED] ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440 Format 1440K floppy `/dev/fd0.1440'? (y/n): y Processing EE^C with /var/log/messages indicating: Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) (and continuing). Additionally, reading a floppy returns errors for any read: (This is a freshly formatted floppy verified on other machines) ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc dd: /dev/rfd0.1440: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.395566 secs (0 bytes/sec) 0 0 0 with /var/log/messages indicating: Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Thanks, -scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld hung up with lots of cron processes
cvsup again. You want to get version 1.134 of sys/vm/swap_pager.c. The fix for your problem was committed 4.5 hours later. Good luck trying to compile the kernel. I had hangs while linking the kernel as well as while trying to install a fixed one. Make sure you have a good backup of the kernel, I ended up with a zero byte kernel while trying to install the fixed one. Jim Bloom [EMAIL PROTECTED] Bob Bishop wrote: Hi, cvsup at Wed Mar 22 04:03:28 GMT 2000, this built without problems with -j8 on my SMP box, but on a uniprocessor (-j4, eveything else the same) something appears to have deadlocked. The machine is generally OK but the build has hung and there are 57 cron processes hanging around (ps ax follows). Any ideas? I'll keep it hanging around for a bit, let me know if you want more info. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world: install-info: unrecognized option
Please read UPDATING for details on how to upgrade to 4.0 from earlier releases. The quick summary to deal with your problem is: make -DNOINFO installworld make installworld There are other problems you might bump into, so do your homework first. Jim Bloom [EMAIL PROTECTED] Rasmus Skaarup wrote: Hiya, I just cvsupped a couple of hours ago, after a successful build, the install phase fails: ** snip snip ** === lib/libcom_err/doc install-info --quiet --defsection="Programming development tools." --defentry="* libcom_err: (com_err).A Common Error Description Library for UNIX." com_err.info /usr/share/info/dir install-info: unrecognized option `--defsection=Programming development tools.' Try `install-info --help' for a complete list of options. *** Error code 1 Stop. ** snip snip ** I'm running 3.4-STABLE, trying to cvsup to cvs-tag RELENG_4. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMD640 and ATA drivers
And I have three machines which I was trying to use for testing -current and my firewall. These machines all have either a CMD640 or an RZ100 controller on the motherboard. (They seemed to be popular with the early Pentium machines.) The controllers seem reliable enough to use for extended periods as test machines. If it gets trashed because of a controller bug, I can simply reinstall and only lose the install time. I upgraded my firewall to an old Adaptec SCSI controller, but I don't care about data integrity on the other machines. Unfortunately, none of them are usable at the moment because of various bugs (panics on boot, not probing the hard drive, etc.). Jim Bloom [EMAIL PROTECTED] Soren Schmidt wrote: It worked until the latest newbus changes, I'm looking at it, but havn't found anything obvious yet. But seriously you want to get another ATA interface, the CMD640 is _broken_ and no software can help that, you are playing russian roulette with your data. Get a promise, abit or siig controller and use that instead... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound driver
Ron 'The InSaNe One' Rosson wrote: I am running CURRENT as of last week. I seem to be only able to get my sound to work when I use: option PNPBIOS device pcm0 Here is the dmesg output: unknown9: ESS0009 at port 0x800-0x807 on isa0 sbc0: ESS ES1879 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,5 on isa0 pcm0: SB DSP 3.01 (ESS mode) on sbc0 unknown10: ESS0001 at port 0x201 on isa0 I would like to get rid of all the unknowns caused by the PNPBIOS option. If anyone has any ideas I am game to try. Try adding "device joy" to your configuration file. The ESS0001 looks like a game/joystick port. Someone might need to add device ID to the driver though. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0R ?
The tag was laid down earlier today. Here is what my current kernel claims to be at the moment: FreeBSD 5.0-CURRENT #31: Mon Mar 13 10:59:41 EST 2000 Actually, there might be a couple fixes slipped in between now and the release, but 4.0R exists. You may cvsup with the tag RELENG_4 now if you like. Jim Bloom [EMAIL PROTECTED] Mike Tancsa wrote: I do follow current, but I must be blind if I missed it. What is the latest date for 4.0R ? Will there be instead another Release Candidate and more testing ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Kris Kennaway wrote: On Thu, 9 Mar 2000, Bush Doctor wrote: Again my libRSAglue libraries before the above were: bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a This was very helpful - I've been able to replicate the problem by install an old libRSAglue of this vintage. It still doesn't answer why on earth make world is trying to link with it, but at least now I have something to look at. Thanks! I looked into this problem a bit as well. I believe it is a build order and dependency problem that shouldn't exist. libkrb is built before libRSAglue and then the shared library is built with -LRSAglue which is only found in /usr/lib. kerberosIV/Makefile.inc has a line "LDADD+= -LRSAglue". This whole issue should not exist simply because libRSAglue is a dummy stub and there is no reson to link anything against it. The quick fix is to remove libRSAglue from the makefiles where it is used. The following makefiles need to have the references to RSAglue removed: usr.sbin/ppp/Makefile usr.sbin/pppd/Makefile secure/libexec/sshd/Makefile kerberosIV/Makefile.inc I don't know how to change ld (compile time?) so that it doesn't look in the standard locations for files during buildworld. That is what is required to guarantee this problem doesn't happen again. Kris, would you like patches or will you edit these yourself? Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
Jim Bloom wrote: The following makefiles need to have the references to RSAglue removed: usr.sbin/ppp/Makefile usr.sbin/pppd/Makefile secure/libexec/sshd/Makefile kerberosIV/Makefile.inc Ignore secure/libexec/sshd/Makefile. That was left over from when I was trying to integrate OpenSSH into the base system before Mark's work was included. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
I am not seeing the problem with a standard build, but I am not building Kerberos. Looking at the makefiles, there is no mentioned of libRSAglue anyplace. The link command doesn't even imply the use of libRSAglue. Also, a buildworld should not be using libraries outside of the build environment. Don't bother building with MAKE_KERBEROS4=NO. All of the tests look at the variable being defined and not its value. You might try removing your object directory and doing a make cleandir twice to make sure nothing is left in source tree that shouldn't be there. Jim Bloom [EMAIL PROTECTED] Bush Doctor wrote: Out of da blue Kris Kennaway aka ([EMAIL PROTECTED]) said: On Thu, 9 Mar 2000, Bush Doctor wrote: Is anyone else seeing this. cvsupped from 12:00 noon EST ... cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../.. /contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHA VE_KERBEROS -DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION -I/usr/obj/usr/src/i386/usr/include -o cvs add.o admin.o buffer.o checkin.o checkout.o c lassify.o client.o commit.o create_adm.o cvsrc.o diff.o edit.o entries.o error.o expand_path.o fileattr.o filesubr.o find_names.o hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o prepen d_args.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o run.o scramble.o server.o status.o subr.o tag.o update.o vers_ts .o version.o watch.o wrapper.o zlib.o /usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../lib/libcvs.a /usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../libdiff/ libdiff.a -lgnuregex -lmd -lcrypt -lz -lkrb -lcrypto -lcom_err /usr/lib/libRSAglue.so.1: undefined reference to `R_RandomUpdate' Did this come up as part of make world? It looks like you have a stale library. It's occurring during a buildworld. If you're referring to libRSAglue being stale it looks like that may be it. bantu.cl.msu.edu:dervish ls -l /usr/lib/libR* -r--r--r-- 1 root wheel 810 Feb 28 22:28 /usr/lib/libRSAglue.a lrwxr-xr-x 1 root wheel 15 Jan 29 07:29 /usr/lib/libRSAglue.so - libRSAglue.so.1 -r--r--r-- 1 root wheel5872 Jan 29 07:29 /usr/lib/libRSAglue.so.1 -r--r--r-- 1 root wheel 868 Feb 28 22:28 /usr/lib/libRSAglue_p.a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More ld-elf.so.1: assert failed messages
NOTE: Take everything I say here as general info. I haven't used these thread packages, but have used others in the past. It should be called somewhere between the starting of the process and the creation of the second thread. There is no problem if there is only one thread. THREAD Create would be fine as long as it sets a variable accessible to all threads indicating dllockinit has been called. Another possible location would be a routine that initialize the multithreading for the process. This routine may not exist in all thread packages though. Jim Bloom [EMAIL PROTECTED] Juergen Lock wrote: In article [EMAIL PROTECTED] you write: In article [EMAIL PROTECTED], Jordan K. Hubbard [EMAIL PROTECTED] wrote: The other possibility would be to fix the wine port so it calls dllockinit() to set up locking. I don't know for sure how hard that would be, but it's probably a feasible solution. To be honest, I'd be the most comfortable with this solution ... As far as I know, Wine is the only port that has problems with the version of the dynamic linker that's in -current at present. I've looked into adding the dllockinit() stuff to Wine, but could use some help from somebody who knows its internals better. Hm you could ask over in comp.emulators.ms-windows.wine... I found the threads primitives, etc., but am not so sure where to place the dllockinit() call. When does it need to be called, just when starting a new thread? (i have looked at the wine source before but never at ld-elf.so...) And would this be the same on -stable and 4.0? Currently you should be able to build a wine on a -stable box and it would still run on 4.0 (well it wouldn't run _worse_ than on -stable), at least thats the idea. Anyway if it should be called before a new thread becomes runnable for the first the i think it could go in THREAD_Create (in scheduler/thread.c), if it needs to be called from within the new thread itself it looks like it should go in THREAD_Start in the same source. HTH, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) 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: no openssh after build
In either case, the answer is that you do not need to install the rsaref port before any builds. It is only a runtime dependency now. Jim Bloom [EMAIL PROTECTED] Walter Brameld wrote: Do you still need to install the rsaref port before openssh? (/usr/ports/security) Ah, sorry. That's for SSL. Not awake yet, I guess.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh question
Warner Losh wrote: First, how does one enable TIS/SKEY authorization for ssh? It appears that the frst step would be to add -DSKEY to the Makefile conditional on something. Are there other steps? Yes, there are other steps. openssh depends upon functions in the openbsd libskey that we do not have. These functions appear to have been added somewhere between our initial version of skey and openbsd's as they exist in openbsd's initial version, but not ours. The skey support in the openssh port has the exact same problems. That being said, if there is some demand for this, I could merge openbsd's libskey into ours and get the skey authentication working. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
John Baldwin wrote: On 06-Mar-00 Kris Kennaway wrote: On Mon, 6 Mar 2000, Oliver Fromme wrote: the ports (yeah, stupid me), to no avail. It complained about some RSA library missing. Did you read the error message? Perhaps you should. Perhaps reporting it here would help someone to actually fix your problem instead of having to guess. I think you've kind of missed the point though, Kris. How many other people are going to upgrade only to find that their previously working system is now broken. We should at least mention this in UPDATING so people have a ghost of a chance. One possible source of breakage is not bringing over the existing server key. The key will need to be moved from /usr/local/etc to /etc/ssh. Did Warner include this with his changes to UPDATING about openssh in the base system (which I haven't seen yet). Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failures
Are you building with -DNOSHARE? That is the only way I can think of off the top of my head. Jim Bloom [EMAIL PROTECTED] Jeff Palmer wrote: Hi all, I have cvsupped and tried to build world mutiple times over the past 3 days, each time I get the same error. I have been following the mailing lists and don't see any other complaints.. So I'm sure the trouble is with my machine... /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `ERR_load_RSAREF_strings' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSA_PKCS1_RSAref' *** Error code 1 Stop in /usr/src/usr.sbin/ppp. *** Error code 1 anyone know what may be causing this, and what I may be able to do, to correct? Please CC: any replies to: [EMAIL PROTECTED] 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: Kernel hangs booting fresh -current
Nik Clayton wrote: On a related note, why does UPDATING say to build and install the kernel, and then reboot, before doing the "installworld"? That contradicts the advice in the Handbook (which I wrote), and I would've thought it's wrong precisely because it allows for things like kernel/mount mismatches to occur. Because the signal interface changed several months ago. If you ran installworld on an old kernel, the machine would panic part way through the install. It is almost impossible to do forward compatibility on major changes. I guess you need to update the handbook to reflect this change. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl current
I am seeing the same thing with a world built yesterday afternoon. I don't know if this is an issue with multiple dlopen'ed libraries or what. Here is what I believe the port is doing. During the build process, the main apache server is built. The ssl layer is created as an add-in module (.so) which I would assume is dlopen'ed. This module is linked as follows: gcc -L/usr/lib -shared -o libssl.so object list -lssl -lcrypto At runtine, apache tries to dlopen libssl.so. libcrypto should dlopen librsaUSA.so. Something doesn't seem to be happening correctly though. My previous test was before librsaUSA was created. Can Peter or John shed any light on possible linker or dynamic loader issues here? Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: On Tue, 29 Feb 2000, Manfred Antar wrote: I needed to add -lRSAglue -lrsaUSA to the SSL_LIBS= line in /usr/ports/www/apache13-php3/work/apache_1.3.12/src/modules/ssl/Makefile and install the recompiled libssl.so in /usr/local/libexec/apache. Works fine Note this is for the apache13-php3 port but I bet it will work for the apache13-php4 port This may work, but I doubt this is necessary. -lRSAglue is an empty library which only exists to keep legacy ports happy, and -lrsaUSA will be automatically dlopen()ed if you have a recent libcrypto.so. As with the other guy, please make sure your libcrypto.so is up to date - I haven't seen evidence from either of you yet that this is the case :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl current
We have found a fix that will change the building of librsaUSA to fix the problem. The fix will get committed after the release engineer approve the commit. The port will not need to be changed in the long run. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: You definitely don't need -lRSAglue. That file is an empty library just for compatibility. The port apache3-modssl worked a couple days ago when I last made a pass through all of the ports using openssl in -current. I'll take a look at it again (by tomorrow) and see where things stand. The recent upgrade of modssl might have caused a problem or broken a patch. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mod_ssl current
You definitely don't need -lRSAglue. That file is an empty library just for compatibility. The port apache3-modssl worked a couple days ago when I last made a pass through all of the ports using openssl in -current. I'll take a look at it again (by tomorrow) and see where things stand. The recent upgrade of modssl might have caused a problem or broken a patch. Jim Bloom [EMAIL PROTECTED] Manfred Antar wrote: I needed to add -lRSAglue -lrsaUSA to the SSL_LIBS= line in /usr/ports/www/apache13-php3/work/apache_1.3.12/src/modules/ssl/Makefile and install the recompiled libssl.so in /usr/local/libexec/apache. Works fine Note this is for the apache13-php3 port but I bet it will work for the apache13-php4 port Manfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cpp change breaks ipfw
No. It has the same bug. That method of concatenation only works for strings. Jim Bloom [EMAIL PROTECTED] Kai Großjohann wrote: / | #define rule(ADDR,MASK) \ | add pass tcp from ADDR ## : ## MASK to any 25 setup | | rule(192.168.2.5,255.255.254.0) \ Does it do what you want? Somewhat clumsy, but it does seem to work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cpp change breaks ipfw
Kai Großjohann wrote: / | $ cat foo | #define rule(ADDR,MASK) add pass tcp from ADDR ## : ## MASK to any 25 setup | rule(192.168.2.5,255.255.254.0) | $ type cpp | cpp is hashed (/usr/bin/cpp) | $ cpp foo | # 1 "foo" | | add pass tcp from 192.168.2.5:255.255.254.0 to any 25 setup | $ cpp --version | 2.95.2 \ Note that there is no space in ``192.168.2.5:255.255.254.0''. I thought that this is what you wanted? If this isn't what you wanted, I'm sorry for the misunderstanding. That small test works fine, but doesn't solve the problem I was having. Try this small test case to see my problem: #define addr 192.186.2.5 #define mask 255.255.240.0 #define rule(ADDR,MASK) add pass tcp from ADDR ## : ## MASK to any 25 setup rule(addr,mask) This also does not work if addr and mask are defined on the command line. The problem arises from using another defined value as the string being concatenated. The concatenation works for constants though. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh uses /etc (bad)
Crypto/ is just a storage location for the for files. They are committed there just like files are in contrib. Buildworld never explicitly goes into either of these directories; the files stored there are referenced by makefiles in other parts of the tree. For example, look at the directory src/secure/usr.bin/ssh. The only file there is Makefile. Reading the Makefile, you will see that it needs several files. These are found through the .PATH derective which references crypto/openssh. Jim Bloom [EMAIL PROTECTED] Ollivier Robert wrote: According to Kris Kennaway: crypto/ is the analogue of contrib/ for crypto code. You're not supposed to build there..look under secure/. I was confused :) "buildworld" is now running on the two machines here... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is openssl/openssh working right yet for others?
Andrew Sherrod wrote: I had similar problems with mod_ssl (for apache). And once I completed that, getting it to install, and for apache to recognize it... Well, actually still working on it. Apache tells me to configure ssl, I do, ssl tells me to run "make certificate" on apache, and I do, apache crashes then tells me to configure ssl... and so on, ad infinitum. Any ideas? There were some patches committed to apache13-modssl and apache13-php3 a little while ago. They fix the build problems and I got apache13-modssl up and running with them without any problems. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yes, current is broke...
Yes it is. strlcat and strlcpy are not needed in libssh since they are in the libc already. They existed in the port because earlier version of 3.x did not have them. Mark is in the middle of committing all of the changes. It might be a little while until everything is clean again. Jim Bloom [EMAIL PROTECTED] Dan Langille wrote: I'm guessing this is related to jkh's mention of OpenSSH coming into the tree, but I'm posting it anyway. Just in case it helps. my cvsup is less then 4 hours old. === libssl cd /usr/src/secure/lib/libssl; make _EXTRADEPEND echo libssl.so.1: /usr/obj/usr/src/secure/lib/libssl/openssl/opensslconf.h .depend === libssh make: don't know how to make strlcat.c. Stop *** Error code 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mergemaster fail with crypto changes
While I was working on this project before I found out that Mark was 95%
done already, I made those tests be:
.in !defined(NO_OPENSSH) !defined(NOCRYPT)
NOCRYPT has been the standard way of indicating that the cryptograph
package has not been installed.
Jim Bloom
[EMAIL PROTECTED]
Munehiro Matsuda wrote:
Hi all,
I don't have crypto in my source tree, because I'm in Japan,
I get following error using mergemaster.
--8-8-Cut here-8-8-
# mergemaster
install: /usr/src/etc/../crypto/openssh/ssh_config: No such file or directory
*** Error code 71
Stop in /usr/src/etc.
*** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the
temproot environment
--8-8-Cut here-8-8-
In /usr/src/etc/Makefile (rev 1.214), it should check for existance of
crypto directory.
--- Makefile.ctmFri Feb 25 11:53:34 2000
+++ MakefileFri Feb 25 13:47:10 2000
@@ -20,7 +20,7 @@
${.CURDIR}/../usr.bin/mail/misc/mail.rc \
${.CURDIR}/../usr.bin/locate/locate/locate.rc
-.if !defined(NO_OPENSSH)
+.if exists(${.CURDIR}../crypto) !defined(NO_OPENSSH)
BIN1+= ${.CURDIR}/../crypto/openssh/ssh_config \
${.CURDIR}/../crypto/openssh/sshd_config
.endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: breakage in make release
David O'Brien committed some changes a few hours ago adding the gasp infodocs into the build. He might have introduced a bug here. Here is the commit message. Jim Bloom [EMAIL PROTECTED] obrien 2000/02/21 12:33:32 PST Modified files: gnu/usr.bin/binutils/doc Makefile gnu/usr.bin/binutils/gasp Makefile Removed files: gnu/usr.bin/binutils/gasp/doc Makefile Log: Build and install gasp's infodocs along side the other binutil docs rather than seperately. Pointed out by: bde Revision ChangesPath 1.4 +3 -2 src/gnu/usr.bin/binutils/doc/Makefile 1.6 +1 -3 src/gnu/usr.bin/binutils/gasp/Makefile Bill Swingle wrote: On Mon, Feb 21, 2000 at 06:21:48PM -0800, Thomas Dean wrote: There were some posts on -current in the past few days about binutils. I believe they were related. Look at the archive on FreeBSD, search current for binutils. Hehe, funny that you would suggest that I should look in the archives since I'm still trying to get them back up again. :) Thanks for the pointer anyway :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fix for problems building openssl ports
I found the problem Jordan and Robert Watson were having building ports that
require rsaref and openssl. The test for whether libcrypto was compiled with
RSA was using shell syntax for executing the command and not make's syntax.
The extra 'true' on the command is to silence make's warning about a non-zero
exit status of the command.
With the fix below, the error about RSA being required is now displayed at
the correct time. This still does not solve the more fundamental problem of
what gets distributed on the CD in terms openssl and RSA.
Jim Bloom
[EMAIL PROTECTED]
--- ports/Mk/bsd.port.mk.orig Sat Feb 19 21:51:49 2000
+++ ports/Mk/bsd.port.mkSat Feb 19 22:00:39 2000
@@ -582,7 +582,7 @@
@${FALSE}
.else
.if ${USE_OPENSSL} == RSA
-_HASRSA= "`/usr/bin/nm /usr/lib/libcrypto.a | /usr/bin/grep RSA_free`"
+_HASRSA!= /usr/bin/nm /usr/lib/libcrypto.a | /usr/bin/grep RSA_free ; true
.if empty(_HASRSA)
.BEGIN:
@${ECHO} "This port requires RSA crypto, which is not present in your"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make world
See the file src/UPDATING. This is one of a couple problems that one sees when trying to install current on an older system. If this error isn't mentioned explicitly, check the sections relating to flags and xinstall (install). Jim Bloom [EMAIL PROTECTED] Omachonu Ogali wrote: Anyone else got this error? -- snip -- === lib/libcom_err/doc install-info --quiet --defsection="Programming development tools." --defentry="* libcom_err: (com_err).A Common Error Description Library for UNIX." com_err.info /usr/share/info/dir install-info: unrecognized option `--defsection=Programming development tools.' Try `install-info --help' for a complete list of options. *** Error code 1 Stop. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with openssl in 4.0rc and ports/security/openssh
The problem initially reported was made worse by a couple of things. First, Kris has not yet committed the changes to the openssh port so that it will issue errors about the cryptography not being installed "correctly". This will not be in all ports that use openssl when 4.0 is released. The ports which will not be modified are the ones which are using configure to find openssl and have not had build problems reported. (I have been looking at bento's error reports, but not on the ports mailing list since I can't handle the additional e-mail volume.) These include several ports which simply disable SSL when they do not link correctly when they test for the existence of openssl (RSA symbols undefined). (If you come across any ports like this, please let Kris and me know so we can patch the port.) I also still have a couple ports in this class to be completed. The ports Kris and I have fixed also will use the system version of openssl over the port if it is installed. Unpatched ports may use either version if the openssl port is installed. Next, the error messages in ports/MK/bsd.ports.mk refer to a section of the handbook which had not been committed when the release candidate was created (and is still not on the web). We still need the packages (USA and international) created to upgrade the cryptography to include RSA. In conclussion, this will never be completed fixed (until all of the legal issues disappear). People will need to manually install upgraded cryptography as part of installing. The original complaint just points out that we are not yet at the point where we want to be for the final release of 4.0, but that was why 4.0RC was created. Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: On Sat, 12 Feb 2000, John Hay wrote: and to me it looks like rsa.h is included: internat:/home/ftp/pub/FreeBSD/releases/i386/4.0-2211-SNAP/des cat des.?? | tar -tzvf - | grep rsa -r--r--r-- root/wheel12208 Feb 12 07:09 2000 usr/include/openssl/rsa.h Or is there something that I miss? That looks right. I think the original person was getting their crypto from the wrong place. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS UP HEADS UP] xinstall now statically linked again.
This won't give you a statically linked install. You might try adding 'NOSHARED=yes' to the make command below. Jim Bloom [EMAIL PROTECTED] Josef Karthauser wrote: I've committed the fix. Another way of not tripping over problems is: # cd /usr/src/usr.bin/xinstall # make clean depend all install This'll give you an install that's statically linked. If your install program is already broken then you'll need to copy the install binary into /usr/bin from your obj tree by hand. Sorry for the inconvenience that this has caused. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING - kernel fails to compile
You still didn't get your installworld to complete succesfully. You have install, libc, and libutil out of sync. I believe the correct procedure for installing everything in your case is: make -k -NOFSCHG installworld make installworld Jim Bloom [EMAIL PROTECTED] Dan Langille wrote: [root@buff:/usr/src/sys/compile/BUFF] # make install install -c -m 555 -o root -g wheel -fschg kernel /kernel /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
This reminds me of a simpler way to do it in the current situation. In all cases except crossbuilding and running the install on the build host with DESTDIR=/mount_point, The folowing command should work: make installworld INSTALL=/usr/obj/usr/src/usr.bin/xinstall/xinstall Jim Bloom [EMAIL PROTECTED] Bruce Evans wrote: Installing the xinstall built by buildworld, with itself, would be safe. Similarly for the new libc -- install it using the new xinstall using something like cd /usr/src/libc MAKEOBJDIRPREFIX=/somehwere INSTALL=/somehwere/.../xinstall install Simpler method: build and install the host xinstall static (NOSHARED=yes) before running installworld. It's too late to do this after installworld corrupts the host's includes and libutil.a. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mail.freebsd.org's host id changed
Will someone please put an MX record up for hub.freebsd.org so it's mail gets rerouted. I have mail queued up for delivery to there. Jim Bloom [EMAIL PROTECTED] Matthew Dillon wrote: : :On Tuesday, 1 February 2000 at 18:49:22 -0800, Matthew Dillon wrote: : Did someone do something to mail.freebsd.org, my ssh is telling me : it's hostid has been changed. : :Right, hub had disk problems, so jmb moved mail to builder. : :Greg Ah, ok. Thanks! Just making sure. -Matt Matthew Dillon [EMAIL PROTECTED] 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: UPDATING
Ruslan Ermilov wrote: On Tue, Feb 01, 2000 at 02:51:11PM -0500, Jim Bloom wrote: I did the following and it worked for me: cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld The first make installworld terminates with an errors, but the second on goes through. It can't be true! Nope, I'm pretty sure that is exactly what I did. After the first `make installworld' fails, we will have: 1) a new `libutil' without string_to_flags() 2) an old `libc' without setflags() 3) an old /usr/bin/install with string_to_flags() linked against libutil. I believe the new libc has been installed as well. My first installworld got an error while trying to install rcp. I believe this is the first program that uses any flags to install. Once you get to this point, all of the libraries have been installed. I believe there is lazy resolution of the library symbols at run time. They are not checked until they are actually referenced, not when the program starts executing. They are first checked when ln is run, but that used consistent versions of the libraries for both version of install. Apparently that (cd /usr/src/usr.bin/xinstall; make install) will fail with `/usr/lib/ld-elf.so.1: install: Undefined symbol "string_to_flags"'. Seems you did something different... maybe you just copied new xinstall over an old /usr/bin/install? I don't believe I copied the executable. I don't have an easy way to go back and test it again. Yesterday, I tried NFS mounting /usr/src and /usr/obj (after a buildworld had completed) on a two week old copy of current (before the commits). That time I simple did a make install for xinstall followed by an installworld. No problems on that test. Jim Bloom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
No, I don;t have the log. It has been overwritten by a newer copy.
I looked into PRECIOUSLIB. It appears to be broken in
/usr/share/mk/bsd.lib.mk. Review this excerpt from the file:
.if defined(PRECIOUSLIB) !defined(NOFSCHG)
SHLINSTALLFLAGS+= -fschg
.endif
_INSTALLFLAGS:= ${INSTALLFLAGS}
.for ie in ${INSTALLFLAGS_EDIT}
_INSTALLFLAGS:= ${_INSTALLFLAGS${ie}}
.endfor
_SHLINSTALLFLAGS:= ${INSTALLFLAGS}
.for ie in ${INSTALLFLAGS_EDIT}
_SHLINSTALLFLAGS:= ${_SHLINSTALLFLAGS${ie}}
.endfor
First, _SHLINSTALLFLAGS is used for install and not SHLINSTALLFLAGS.
This then uses uses INSTALLFLAGS twice. Try the patch below if you want
to fix the problem. (It may have whitespace errors from cut and paste
and a missing empty line.)
--- bsd.lib.mk.orig Wed Feb 2 11:50:59 2000
+++ bsd.lib.mk Wed Feb 2 11:51:31 2000
@@ -280,8 +280,8 @@
.for ie in ${INSTALLFLAGS_EDIT}
_INSTALLFLAGS:=${_INSTALLFLAGS${ie}}
.endfor
-_SHLINSTALLFLAGS:= ${INSTALLFLAGS}
-.for ie in ${INSTALLFLAGS_EDIT}
+_SHLINSTALLFLAGS:= ${SHLINSTALLFLAGS}
+.for ie in ${SHLINSTALLFLAGS_EDIT}
_SHLINSTALLFLAGS:= ${_SHLINSTALLFLAGS${ie}}
.endfor
Jim Bloom
[EMAIL PROTECTED]
Ruslan Ermilov wrote:
Yeah, just figured this myself, but one thing I still don't understand
is how the new libc.so.4 gets installed on the first pass? The problem
is that it is declared as PRECIOUSLIB in libc/Makefile, this will result
in -fschg passed to install. Do you have a log from the first failed
installworld?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mail.freebsd.org's host id changed
John Polstra wrote: In article [EMAIL PROTECTED], Jim Bloom [EMAIL PROTECTED] wrote: Will someone please put an MX record up for hub.freebsd.org so it's mail gets rerouted. I have mail queued up for delivery to there. Why are you addressing mail to [EMAIL PROTECTED]? The correct address to use is [EMAIL PROTECTED] Because I replied to a message I received which had [EMAIL PROTECTED] The message originated on hub and I guess the sender's address was not rewritten. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [install-tools stage in Makefile.inc1] (was: Re: 3.4-4.0 ... *almost* ...)
Ruslan Ermilov wrote: texinfo is already in bootstrap tools. The problem is that we do not have such a thing like `install' tools. Apparently, every tool we are using at installworld stage, should be compiled `static' at buildworld stage, and then these tools should be used at installworld. Among these tools, there should be at least xinstall and install-info. Don't forget the cross platform installation issues. If the installworld is executed on the target machine with the host machine's build area mounted, then this works fine. If you have the target machine's root mounted on the host machine, you can't use anything out of the build area. I could MFC the -current texinfo into -stable, so installworld of -current would be possible from the latest -stable, but... Another possibility would be to add install-tools target to Makeinfo.inc1 to statically build install tools like xinstall and install-info, and use them at installworld stage. I will prepare the patch tomorrow, will test it on my -stable machine, and will then send it to -current. The problem with install-info is not a linkage problem, but a feature change between the versions. So far I don't see a reason to to link it 'static'. I believe what needs to be done in this case is to ensure that install-info is installed before it is used. I suspect that a bit of careful addition of early installs in the middle of installworld will solve this problem. Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
I did the following and it worked for me: cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld The first make installworld terminates with an errors, but the second on goes through. I don't see any reason why the following wouldn't work as well: cd /usr/src make buildworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld I just NFS mounted a completed buildworld on my laptop (which had a two week old -current) and I am trying this as I type. It is a slow machine, so it might take a while. I'll post an update when it completes. Jim Bloom [EMAIL PROTECTED] Warner Losh wrote: In message [EMAIL PROTECTED] Max Khon writes: : actually instructions are wrong. : you can't build xinstall before `make buildworld' now with old libc. I've seen multiple, conflicting reports on this. I've not personally hit this bug. What's the exact sequence one must do? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
The method below worked just fine on my laptop. I can't guarantee how it will do on a 3.x system for upgrading. Also, if a kernel is being installed, it must be done before installing install or after the installworld. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: I don't see any reason why the following wouldn't work as well: cd /usr/src make buildworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld I just NFS mounted a completed buildworld on my laptop (which had a two week old -current) and I am trying this as I type. It is a slow machine, so it might take a while. I'll post an update when it completes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More breakages
It looks like your last make world or make installworld did not complete. There is an install problem with installworld bootstrapping itself. New libraries are installed before the install binary is installed. When they try to use the "-fschg" option, you get that error. (installworld aborts at rcp with the same problem.) Simple recompile and install /usr/src/usr.bin/xinstall to fix both of these problems. Jim Bloom [EMAIL PROTECTED] Forrest Aldrich wrote: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c linking kernel textdata bss dec hex filename 1807056 139340 115448 2061844 1f7614 kernel chflags noschg /kernel mv /kernel /kernel.old install -c -m 555 -o root -g wheel -fschg kernel /kernel /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 This is from a cvsup I just performed minutes ago, FYI. 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: kernel breakage from ipfw6?
The problem here is that ip6_fw.c is dependent upon INET6 instead of IPv6FIREWALL. I sent mail to shin a little while ago about the problem. If you want to compile a kernel in the interim, change the line for ip6_fw.c in sys/conf/files to netinet6/ip6_fw.c optional ipv6firewall I believe this is the correct fix in any case. Jim Bloom [EMAIL PROTECTED] Kris Kennaway wrote: I get this whenever I try and build a kernel (with or without IPFIREWALL): linking kernel.debug ip6_fw.o: In function `ip6_fw_init': /sys/compile/MORDEN/../../netinet6/ip6_fw.c(.text+0x18a4): undefined reference to `ip6_fw_chk_ptr' /sys/compile/MORDEN/../../netinet6/ip6_fw.c(.text+0x18ae): undefined reference to `ip6_fw_ctl_ptr' *** Error code 1 1 error I've just verified my sources are up-to-date from cvsup3. Kernel config: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
In the cross-build case, I would guess that the 'make installworld' could be run on either machine. It would depend upon which way the mounts are done. Is the host machine mounted on the target machine or the other way around. Some people strongly believe it should be one way or the other. Optimally, both cases should be handled correctly. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: Hmm, ok. I think my terminology may have been poor. I meant that the new sources should have been used to build the tools, but using the existing machine headers/libraries to build the static binaries. One question though, what architecture *should* the install-tools be? Normally, one would run installworld on the target machine and not necessarily the host machine. For example, if I was cross-building an axp world on my x86 machine, then I would want to run 'make buildworld' on the x86, but would want to run 'make installworld' on the axp. Thus, the build tools in that case need to be x86 binaries, but the install tools need to be axp binaries. Of course, in that case you can't use the build machine's header files or libraries to build the install tools. Thus, you could use the headers/binaries in the source tree, except that you might then end up linking against a newer libc that needs a newer kernel to run. The other choice is to build the install tools during installworld using the target machine's headers/libraries, but then installworld would no longer be a read-only operation. :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installworld fialed
Yes, I had the same problem. I simply removed /usr/share/info and ran
installworld again. I don't know what you might lose if you try this,
but I don't use info much so I didn't really care.
Jim Bloom
[EMAIL PROTECTED]
"T. Hsiang" wrote:
Does anyone have the same problem?
--
=== gnu/usr.bin/texinfo
=== gnu/usr.bin/texinfo/libtxi
=== gnu/usr.bin/texinfo/makeinfo
install -c -s -o root -g wheel -m 555 makeinfo /usr/bin
install -c -o root -g wheel -m 444 makeinfo.1.gz /usr/share/man/man1
=== gnu/usr.bin/texinfo/info
install -c -s -o root -g wheel -m 555 info /usr/bin
install -c -o root -g wheel -m 444 info.1.gz /usr/share/man/man1
install -c -o root -g wheel -m 444 info.5.gz texinfo.5.gz /usr/share/man/man5
=== gnu/usr.bin/texinfo/install-info
install -c -s -o root -g wheel -m 555 install-info /usr/bin
install -c -o root -g wheel -m 444 install-info.1.gz /usr/share/man/man1
=== gnu/usr.bin/texinfo/texindex
install -c -s -o root -g wheel -m 555 texindex /usr/bin
install -c -o root -g wheel -m 444 texindex.1.gz /usr/share/man/man1
=== gnu/usr.bin/texinfo/doc
sflag=`grep -q ^INFO-DIR-SECTION info.info || echo 1`; eflag=`grep -q
^START-INFO-DIR-ENTRY info.info || echo 1`; install-info
${sflag:+--section=Miscellaneous} ${eflag:+--entry=} info.info /usr/share/info/dir
sflag=`grep -q ^INFO-DIR-SECTION info-stnd.info || echo 1`; eflag=`grep -q
^START-INFO-DIR-ENTRY info-stnd.info || echo 1`; install-info
${sflag:+--section=Miscellaneous} ${eflag:+--entry=} info-stnd.info
/usr/share/info/dir
sflag=`grep -q ^INFO-DIR-SECTION texinfo.info || echo 1`; eflag=`grep -q
^START-INFO-DIR-ENTRY texinfo.info || echo 1`; install-info
${sflag:+--section=Miscellaneous} ${eflag:+--entry=} texinfo.info
/usr/share/info/dir
install-info: menu item `makeinfo' already exists, for file `makeinfo'
*** Error code 1
Stop in /usr/src/gnu/usr.bin/texinfo/doc.
*** Error code 1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/secure/lib/libcrypto Makefile.inc Makefile
Add lynx-ssl to the list of ports which are broken on current. This was
as of Jan. 16 at 14:00 EST cvsup of ports and source followed by a make
world.
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
On 17 Jan 2000, Satoshi - Ports Wraith - Asami wrote:
Should I add some stuff to handle the differences in bsd.port.mk (like
we did with perl5)?
It may be useful - although there are a lot of inconsistencies in how the
openssl ports look for it. Dirk Froemberg was going to help with this -
I'm not sure exactly what the best way to do it is. For example, ports
like w3m-ssl pass the location of the openssl include directory, which
needs to be either /usr/include or ${LOCALBASE}/include. Perhaps the best
thing would be to bump OSVERSION (belatedly).
Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/secure/lib/libcrypto Makefile.inc Makefile
Here is the sequence I used for installing thing yesterday when I had
the problem. First, I cvsup'ed and did a make world. Next, I installed
the rsaref-2.0 port. Finally, I tried to make the lynx-ssl port.
The basic problem is that some of the include files are not being found
(ssl.h and crypto.h). I haven't read everything closely, but I believe
that the source uses
#include ssl.h
#include crypto.h
and puts -I${PREFIX}/include/openssl (in the Makefile) in CFLAGS. This
might be fixed by changing the source to
#include openssl/ssl.h
#include openssl/crypto.h
and having -I${PREFIX}/include in CFLAGS.
Here is the build log minus the configuration output:
=== Extracting for lynx-ssl-2.8.2.1
Checksum OK for lynx2.8.2rel.1.tar.gz.
Checksum OK for lynx-282-ssl.patch.gz.
=== lynx-ssl-2.8.2.1 depends on executable: openssl - found
=== lynx-ssl-2.8.2.1 depends on shared library: crypto.1 - found
=== lynx-ssl-2.8.2.1 depends on shared library: ssl.1 - found
=== Patching for lynx-ssl-2.8.2.1
=== Applying distribution patches for lynx-ssl-2.8.2.1
=== Applying FreeBSD patches for lynx-ssl-2.8.2.1
=== Configuring for lynx-ssl-2.8.2.1
... (Config deleted) ...
=== Building for lynx-ssl-2.8.2.1
PATH=.:$PATH; export PATH; /bin/sh -c './cfg_defs.sh'
Constructing sed-script
sed -e '/^#/d' -e '/^$/d' -e 's%\(.*\)=\(.*\@.*\)$%s=@\1@=\2=g%'
-e 's%\(.
*\)=\(http:.*\)$%s=@\1@=\2=g%' -e 's%\(.*\)=\(ftp:.*\)$%s=@\1@=\2=g%'
-e 's%\(
.*\)=\(.*\.html\)$%s=@\1@=\2=g%' ./lynx_help/help_files.txt | tr '='
'%' hel
p_files.sed
Creating LYHelp.h
**
Help files will NOT be gzipped.
**
cd WWW/Library/Implementation make CC="cc" LY_CFLAGS="-O -pipe
-I/usr/local/
include/openssl" CPPFLAGS="" LYFLAGS="-I/usr/local/include -DUSE_SSL"
cc -DHAVE_CONFIG_H -I/usr/local/include -DUSE_SSL -I../../..
-I../../../src
-I../../.. -I../../../src -I../../../WWW/Library/Implementation -O
-pipe -I/u
sr/local/include/openssl -I/usr/local/include -DUSE_SSL
-I../../../WWW/Library/
Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c
../../../WWW/Library/Implementat
ion/HTParse.c
cc -DHAVE_CONFIG_H -I/usr/local/include -DUSE_SSL -I../../..
-I../../../src
-I../../.. -I../../../src -I../../../WWW/Library/Implementation -O
-pipe -I/u
sr/local/include/openssl -I/usr/local/include -DUSE_SSL
-I../../../WWW/Library/
Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c
../../../WWW/Library/Implementat
ion/HTAccess.c
cc -DHAVE_CONFIG_H -I/usr/local/include -DUSE_SSL -I../../..
-I../../../src
-I../../.. -I../../../src -I../../../WWW/Library/Implementation -O
-pipe -I/u
sr/local/include/openssl -I/usr/local/include -DUSE_SSL
-I../../../WWW/Library/
Implementation/ -DXMOSAIC_HACK -DACCESS_AUTH -c
../../../WWW/Library/Implementat
ion/HTTP.c
../../../WWW/Library/Implementation/HTTP.c:15: ssl.h: No such file or
directory
../../../WWW/Library/Implementation/HTTP.c:16: crypto.h: No such file or
directo
ry
../../../WWW/Library/Implementation/HTTP.c:75: syntax error before `*'
../../../WWW/Library/Implementation/HTTP.c:75: warning: data definition
has no t
ype or storage class
../../../WWW/Library/Implementation/HTTP.c:83: syntax error before `*'
../../../WWW/Library/Implementation/HTTP.c: In function
`HTGetSSLHandle':
../../../WWW/Library/Implementation/HTTP.c:90: warning: assignment makes
pointer
from integer without a cast
../../../WWW/Library/Implementation/HTTP.c:91: request for member `cert'
in some
thing not a structure or union
../../../WWW/Library/Implementation/HTTP.c:100: warning: return makes
pointer fr
om integer without a cast
../../../WWW/Library/Implementation/HTTP.c: In function `HTLoadHTTP':
../../../WWW/Library/Implementation/HTTP.c:178: `SSL' undeclared (first
use in t
his function)
../../../WWW/Library/Implementation/HTTP.c:178: (Each undeclared
identifier is r
eported only once
../../../WWW/Library/Implementation/HTTP.c:178: for each function it
appears in.
)
../../../WWW/Library/Implementation/HTTP.c:178: `handle' undeclared
(first use i
n this function)
../../../WWW/Library/Implementation/HTTP.c:323: warning: passing arg 1
of `HTPro
gress' makes pointer from integer without a cast
*** Error code 1
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
On Mon, 17 Jan 2000, Jim Bloom wrote:
Add lynx-ssl to the list of ports which are broken on current. This was
as of Jan. 16 at 14:00 EST cvsup of ports and source followed by a make
world.
Well, that makes a list of one. Can you provide more information (e.g. a
transcript?) Are you using openssl-rsaref, or openssl with no RSA (the
latter will break many ports, the former has a restrictive license).
Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 testing...willing to help
I found the problems I was seeing. I had an old configuration of dhclient dating from before it was integrated into FreeBSD. At that time, I just called dhclient without specifying the interface. (I only had one NIC.) Dhclient then tried using all interfaces it could find. One of the interfaces it tried to use was faith0 which generated all of the errors. I just fixed by network startup to specify the interface for dhclient and all of the error messages went away. Jim Bloom [EMAIL PROTECTED] Jim Bloom wrote: I added the options a couple weeks ago. Everthing has been working fairly well. Two issues I have seen which I haven't verified if they are are related to INET6 or something else. First, ever since I added INET6, I have been seeing errors like looutput: af=0 unexpected (or something close to that) These are appearing frequently (several a minute). (There also is no newline after this error message in the kernel.) I ran cvsup around 15:00 EST today and built world and a new kernel. After rebooting, I started getting error messages from dhclient about unsupported address families. I haven't looked into this to determine if dhclient is working correctly and reporting warnings or is not working at all. I'll try to do some more checking later tonight or tomorrow. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
My machine is dual boot and I don't have time to reboot now. (I need to get some sleep.) I'll provide what information I can quickly and will test things further tomorrow evening. I was seeing the core dumps from gui cvsup. My current was a couple different cvsup runs on Saturday and Sunday. I am using the static binary installed from the ports collection. I don't have a date or version right now, but seem to recall it being 16.0. As others have mentioned, running cvsup under truss works. I'll let you know more tomorrow night if there is anything I can add. Jim Bloom [EMAIL PROTECTED] John Polstra wrote: I've seen a few reports that CVSup has suddenly started dumping core on a segmentation violation under -current, but I need more information. For starters, I would like to know whether the static binary (ports/net/cvsup-bin) works or not under the very latest -current on the i386. Could somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. Also, for those of you who are experiencing problems: Please state as precisely as possible: - which vintage of -current are you running? - what is the output from "cvsup -v"? - is "cvsup" a static binary or is it dynamically linked? - did you build it, or did you simply install a binary? - if you built it, when did you build it? Note, you are going to have trouble getting much out of the core dumps from the binaries, because they're a.out. I've placed an unstripped ELF binary here if you'd like to help out by getting a stack trace: http://www.freebsd.org/~jdp/cvsup-16.0.gz The compressed file is about 2.3 MB in size. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron 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: Problems with ahc (2940U2W) and USB
Add me to the list of people seeing this problem. I have an ASUS P2B-S with onboard Adaptec 7890. I have been seeing the problem on and off since December of last year. One time it boots and the next time it doesn't. Once the disk is hung, the reset switch or power cycling are the only ways to unfreeze it. I have seen this problem mentioned on both freebsd-current and freebsd-scsi several times without a solution. I don't recall a link to USB being mentioned before. I'll try to post my dmesg output later this tonight. Jim Bloom bl...@acm.org Rick Whitesel wrote: Hi: I am seeing the same thing on a ASUS P2B with a Adaptec 2940?? controller. Rick - Original Message - From: e...@habatech.no To: freebsd-current@FreeBSD.ORG Sent: Wednesday, April 28, 1999 11:38 AM Subject: Problems with ahc (2940U2W) and USB With the current sources, there seems to be a problem with the Adaptec 2940U2W driver when using USB. Whenever I try to boot a kernel with the USB driver, the boot process gets to the Waiting 15 seconds for SCSI devices to settle and stops. If I compile a kernel with an nearly identical config, only the USB driver has been commented out, it boots all right. My computer has a Spacewalker 661 mainboard, which is a 440BX based card. The SCSI controller is an Adaptec 2940U2W. Kernels compiled before the integration of new-bus works fine. Now, this is not a critical situation for me, as I have no USB devices, but I thought someone else would want this information. Anyone else experiencing this? -- +---+ Erik H. Bakke, Habatech AS | To be or not to be... | E-Mail: e...@habatech.no| Is simply a question of binary logic. | This message was sent by XFMail | | +---+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Hang during boot with ahc (2940U2W)
Here is the dmesg output from a boot -v on my machine. I don't believe that I have ever had the USB ports configured in my kernel. They do have an IRQ allocated in the BIOS though. Jim Bloom bl...@acm.org Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #19: Sat Apr 10 14:19:12 EDT 1999 bl...@jbloom.ne.mediaone.net:/usr/src/sys/compile/JMB Calibrating clock(s) ... TSC clock: 400903902 Hz, i8254 clock: 1193167 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0032d000 - 0x07ffbfff, 130871296 bytes (31951 pages) config pnp 1 0 os enable irq0 5 drq0 1 drq1 5 port0 0x220 port1 0x330 port2 0x388 config pnp 1 1 os enable port0 0x200 config pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 config ls Device port irq drq iomem iosize unit flags enab confl fdc0 0x3f0 6 2 0 00 0 Yes No wdc0 0x1f0 14-10 00 0xa0ffa0ff Yes No wdc1 0x170 15-10 01 0xa0ffa0ff Yes No atkbdc0 0x60 -1-10 00 0 Yes No atkbd0 0x 1 -10 00 0 Yes No psm0 0x 12-10 00 0 Yes No sc0 0x -1-10 00 0 Yes No sio0 0x3f8 4 -10 00 0x10 Yes No sio1 0x2f8 3 -10 01 0 Yes No ppc0 0x 7 -10 00 0 Yes No pca0 0x40 -1-10 00 0 Yes No vga0 0x -1-10 00 0 Yes Yes npx0 0xf0 13-10 00 0 Yes No apm0 0x -1-10 00 0x31 No No sb0 0x220 5 1 0 00 0 Yes No sbxvi0 0x -15 0 00 0 Yes No sbmidi0 0x330 -1-10 00 0 Yes No awe0 0x620 -1-10 00 0 Yes No opl0 0x388 -1-10 00 0 Yes No joy0 0x201 -1-10 00 0 Yes No CSN LDN conf en irqs drqs others (PnP devices) 1 0 OSY 5 0 1 5 port 0x220 0x330 0x388 1 1 OSY 0 0 0 0 port 0x200 1 2 OSY 0 0 0 0 port 0x620 0xa20 0xe20 config quit avail memory = 127430656 (12K bytes) Found BIOS32 Service Directory header at 0xc00f9ce0 Entry = 0xf0550 (0xc00f0550) Rev = 0 Len = 1 PCI BIOS entry at 0x750 DMI header at 0xc00f5880 Version 2.0 Table at 0xf589a, 33 entries, 1079 bytes Other BIOS signatures found: ACPI: $PnP: 000fd110 Preloaded elf kernel kernel at 0xc0318000. Preloaded userconfig_script /pnp.setup at 0xc03180a8. Pentium Pro MTRR support enabled, default memory type is uncacheable GPL Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Probing for devices on PCI bus 0: found- vendor=0x8086, dev=0x7190, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 3, range 32, base e400, size 26 chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0 found- vendor=0x8086, dev=0x7191, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0 found- vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.4.0 found- vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base c800, size 4 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.4.1 intel_piix_status: primary master sample = 5, master recovery = 4 intel_piix_status: primary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: primary slave sample = 3, slave recovery = 1
Re: swap-related problems
A signal handler is not guaranteed to work. It must be written such that it does not require a new page of memory. Some possible problems here are the stack growing, writing on a new page in the data segment, etc. I'm not familiar enough with the VM system, but if you couldn't create a new swap page for a process, what would guarantee that the signal handler could get the pages it needs. Jim Bloom bl...@acm.org Mikhail Teterin wrote: If we are up to discussing the possible implementations, I'd suggest that the system uses something other then SIGKILL to notify the program it's time to pay for the over-commit speed and convenience. I think, SIGBUS is appropriate, but I'm not sure. Anything a program can _catch_ and react upon, if its author chooses to. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
I get the same error. This is more to the error message which I have included below. I am doing a make buildworld after deleting everything in /usr/obj. Cvsup from freebsd3.freebsd.org at around 21:00 GMT. Jim Bloom bl...@acm.org c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o In file included from /usr/obj/usr/src/tmp/usr/include/g++/osfcn.h:5, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include/posix.h:25, from /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc:24: /usr/obj/usr/src/tmp/usr/include/g++/std.h:23: stddef: No such file or directory *** Error code 1 Stop. David O'Brien wrote: c++ -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -fno-for-scope -I/usr/src/gnu/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_STDLIB_H=1 -DUNISTD_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DSTDIO_H_DECLARES_POPEN=1 -DSTDIO_H_DECLARE_PCLOSE=1 -DHAVE_CC_OSFCN_H=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/usr/src/tmp/usr/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/libgroff/../../../../contrib/groff/libgroff/new.cc -o new.o *** Error code 1 Did you get any other output? While ``make'' saw an error, ``c++'' didn't report it for some reason. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
This seems to fix the problem. I got all the through buildworld and have installed the code. Man(1) seems to work fine, but I haven't done a major stress test of groff and the related programs. Jim Bloom bl...@acm.org David O'Brien wrote: I've hit this one now too. I'm trying to duplicate the problem. My guess at the fix is to remove the -DHAVE_CC_OSFCN_H=1\ line from src/gnu/usr.bin/groff/Makefile.cfg. But I can't tell what other problems this may cause. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
I believe that (uid_t)-2 has a lot to do with the user nobody. That was the historical reason why the uid 65534 for chosen for nobody back when uid_t was only 16 bits. I would recommend that the default mapped uid for root be defined as 65534 instead of (uid_t)-2. This seems to make the most sense when trying to avoid user suprises. I would also suggest the default gid be changed similarly. (On Solaris 2.5.1, nobody is now uid 60001 with nobody4 as uid 65534 (for SunOS 4).) Jim Bloom bl...@acm.org Bruce Evans wrote: 4294967294 is just the default mapped uid for root. It is (uid_t)-2. See mountd sources. It has nothing to do with user nobody or 65534, except possibly on buggy clients that silently truncate it mod 65536. Perhaps it is a bug to use (uid_t)-2 instead of 65534. For clients with only 16-bit uid_t's you would want to keep all uids on the server 65536. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Floppy Tape Driver.....
I used to run a 250Mb with extended length tapes (350Mb). That is still far short of the size of newer tape drives. Jim Bloom bl...@acm.org Poul-Henning Kamp wrote: In message xfmail.990206114740.wwo...@cybcon.com, William Woods writes: Yea yea, I know..but this was a gifyt for Christmass and I really dont have any extra $$ right nowso where is the floppy tape driver? Btw, if this is a new device, it is unlikely that the ft driver will support it anyway, I don't think it ever came above the 80Mbyte tapes... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
