Re: convert libgmp to a port?
Steve Kargl wrote:
On Sun, Jun 17, 2001 at 05:48:48AM +0300, Giorgos Keramidas wrote:
I dont seem to be able to find some part of the base system that
actually *does* use libgmp. Being out of date as it is, do you think
it's proper to remove it from the base system and make it a port?
It is a port. See ports/math/libgmp3. Note also that libmp depends
on sources from libgmp.
kargl[219] find . -name Makefile | xargs grep lmp
./kerberosIV/libexec/telnetd/Makefile: -L${KRBOBJDIR} -lkrb -lcrypt
-lcom_err -lmp ${MINUSLPAM}
./kerberosIV/usr.bin/telnet/Makefile: -L${KRBOBJDIR} -lkrb -lcrypt
-lcom_err -lmp -lipsec ${MINUSLPAM}
./secure/libexec/telnetd/Makefile: -lcrypt -lmp ${MINUSLPAM}
./secure/usr.bin/telnet/Makefile:LDADD= -ltermcap ${LIBTELNET} -lcryp
to -lcrypt -lmp \
./usr.bin/chkey/Makefile:LDADD= -lrpcsvc -lmp -lgmp
./usr.bin/newkey/Makefile:LDADD=-lrpcsvc -lmp -lgmp
./usr.sbin/keyserv/Makefile:LDADD= -lmp -lrpcsvc
kargl[220] find . -name Makefile | xargs grep lgmp
./usr.bin/chkey/Makefile:LDADD= -lrpcsvc -lmp -lgmp
./usr.bin/newkey/Makefile:LDADD=-lrpcsvc -lmp -lgmp
It should not be too hard to have build a lightweight 'libbignum' that
is extracted from the openssl sources and make that available in the base
system. It would not be hard to convert the lib*mp consumers to use the
libbignum (libbn, -lbn ?) and then we can get rid of it.
telnet* should never have used libmp in the first place, it should have
used libcrypto/bignum. chkey/newkey/keyserv are using libmp for
diffie-helmann key exchange. (just large integer multiplication). It
should be really easy to convert those three.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
y]ExTCgzWubNX
y]ExTCgzWubNX http://www.job-rex.com/ ͶßܵÄAWubNXÅ·B ËRÅ·ª ¡¢Ä¢éïÐÌ]¿É«µÄ¢Ü·©H WubNXÍ»ÝLAAbv®ÌlA sÍ é¯ÇdddAÆ¢¤lÌ®ðx·é LAAbvxTCgÅ·B ¡ÜÅ]E®Å¬Êðã°éªoÈ©Á½ûàA WubNXÅ]EÌLAAbvI léÆâåWEíÉ¢ÄÌÚ×ÍgoŲÉÈêÜ·ªA s¾È_ª êμÚAdbâ[ÅÈPÉâ¢í¹·éàÅ«Ü·B ڵͱ¿ç« http://www.job-rex.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mdconfig/umount Fatal trap 12
hello, world\n with a system cvsupped June 6th I can reliably reproduce a Fatal trap 12: page fault while in kernel mode fault virtual address = 0x22 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b67e2 stack pointer = 0x10:0xc8f7aea0 frame pointer = 0x10:0xc8f7aea8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 832 (umount) panic: from debugger panic: from debugger Uptime: 10m3s dumping to dev da2s1b, offset 352280 when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Steve O'Hara-Smith writes: : I would argue loud and long that changing that *would* be broken. There : is never a guarantee (or even an implication) that a symlink points to a : valid directory entry (think unmounted filesystems, NFS ...). I find it hard : to imagine why creation time should be special in that regard. And it would break /etc/malloc.conf! I'd have to agree 100% here. No, it (disallowing null symlinks, not disallowing symlinks to nonexistent files!!!) wouldn't break /etc/malloc.conf. ln -fs '' /etc/malloc.conf would simply fail after unlinking /etc/malloc.conf. There would then be no /etc/malloc.conf, which gives exactly the same behaviour as when /etc/malloc.conf is a null symlink. BTW, even ln(1) doesn't understand null symlinks: root$ cd /tmp # a safe place to clobber root$ ln -fs aj /etc/malloc.conf# my usual malloc.conf root$ ln -fs a /etc/malloc.conf# normal changes to it work root$ ln -fs '' /etc/malloc.conf# change it to null (works) root$ ln -fs aj /etc/malloc.conf# attempt to change it back root$ ls -l /etc/malloc.conf# change didn't work: lrwxr-xr-x 1 root wheel 0 Jun 17 22:15 /etc/malloc.conf - root$ ls -l /aj # change clobbered root dir: lrwxr-xr-x 1 root wheel 2 Jun 17 22:31 /aj@ - aj So disallowing null symlinks would actually unbreak /etc/malloc.conf. Further debugging shows that the main bug is in the kernel. stat(2) on a null symlink bogusly succeeds and classifies the symlink as a directory. ln(1) just believes this so it rewrites ln -fs aj /etc/malloc.conf to ln -fs aj /etc/malloc.conf/aj. The kernel then resolves /etc/malloc.conf/aj to /aj. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 23:02:50 +1000, Bruce Evans wrote: So disallowing null symlinks would actually unbreak /etc/malloc.conf. Further debugging shows that the main bug is in the kernel. stat(2) on a null symlink bogusly succeeds and classifies the symlink as a directory. ln(1) just believes this so it rewrites ln -fs aj /etc/malloc.conf to ln -fs aj /etc/malloc.conf/aj. The kernel then resolves /etc/malloc.conf/aj to /aj. And this should be fixed, as I say from the very beginning. (strangely, most people here mistreat null symlinks we discuss as non-null symlinks with non-existen targets) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: convert libgmp to a port?
On Sat, Jun 16, 2001 at 11:38:45PM -0700, Peter Wemm wrote: It should not be too hard to have build a lightweight 'libbignum' that is extracted from the openssl sources and make that available in the base system. It would not be hard to convert the lib*mp consumers to use the libbignum (libbn, -lbn ?) and then we can get rid of it. telnet* should never have used libmp in the first place, it should have used libcrypto/bignum. chkey/newkey/keyserv are using libmp for diffie-helmann key exchange. (just large integer multiplication). It should be really easy to convert those three. Since there are a few things that are using libgmp (and I missed them in my quick search through the sources), no I would not prefer removing libgmp and making a new, probably buggier, libbignum that will replace our current libgmp. If we do need some of the functionality of libgmp in the base-system, then we really should import some newer version of libgmp, instead of trying to make our own new library. I dont really like reinventing wheels :) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: convert libgmp to a port?
On Sun, 17 Jun 2001, Giorgos Keramidas wrote: If we do need some of the functionality of libgmp in the base-system, then we really should import some newer version of libgmp, instead of trying to make our own new library. I dont really like reinventing wheels :) Unless you are the one charged with doing the work, you shouldn't complain about the circumstances of the job. If someone wants to implement something which already exists with a good reason for doing so, let them. It can't hurt. Honestly, the odds that you would end up doing this, are NULL. Giving concise reasons as to why it doesn't need replaced would be nice, rather than why not bring in more vendor code. -- [ Joseph Mallett[EMAIL PROTECTED] ] [ http://srcsys.org ] [ xMach Core Team xMach: Proactively Unbloated Microkernel BSD ] [ FreeBSD, NetBSD, xMach User; (Obj)C(++) Coder ] [ http://xMach.org ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SCSI hangs w/SuperMicro 6010H
Please excuse me if you've seen this in questions, but I found a relevancy to current: If I drop back to 4.3 release, this system boots every time with no hangs observed in half a dozen tries in either UP or SMP mode. Anyone else seeing similar? thanks, dave c - Forwarded message from Dave Cornejo - From: Dave Cornejo [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Subject: SuperMicro 6010H SCSI Problems To: [EMAIL PROTECTED] Date: Sun, 17 Jun 2001 00:20:47 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL88 (25)] I finally got a make release done (a heartfelt thanks to all the people I badgered to commit fixes for that!) and installed it. I'm having a problem with a SuperMicro 6010H server (uses a 370DER+ motherboard), dual 1GHz PIII, 1GB RAM, 2 x Seagate ST318451LC drives (18GB 15K RPM Ultra160 SCSI). The SCSI chip is an Adaptec 7899. The software is several different kernels from today (June 16) cvsupped at various times. It seems to boot okay with a non-SMP kernel, but hangs with an SMP one. It seems to revolve around the SCSI stuff, I did a boot -v and tried to get into the debugger but it's hung hard. Oddly sometimes if you pound on the keyboard at the right point (noted in the edited output of dmesg below) it will continue on to boot, but you get tons of Retrying commands and tagged openings now XXX before things settle out and all seems to work okay after that. Another tidbit: swapped the drives and reinstalled and the command retries aren't happening (at least not as quickly or often), but the hang is still there. Any clues would be appreciated... dave c what I hope are the relevant bits of dmesg: ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeafc000-0xfeafcfff irq 5 at device 5.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Manual LVD Termination ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 419 instructions downloaded aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 7 at device 5.1 on pci0 ahc1: Reading SEEPROM...done. ahc1: Manual LVD Termination ahc1: BIOS eeprom is present ahc1: Secondary High byte termination Enabled ahc1: Secondary Low byte termination Enabled ahc1: Primary Low Byte termination Enabled ahc1: Primary High Byte termination Enabled ahc1: Downloading Sequencer Program... 419 instructions downloaded aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs ... BIOS Geometries: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 1:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 ... Waiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (probe0:ahc0:0:0:0): Retrying Command (probe1:ahc0:0:1:0): Retrying Command (ahc0:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:0:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 0 using 16bit transfers ahc0: target 0 synchronous at 80.0MHz DT, offset = 0x3f (ahc0:A:1:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:1:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 1 using 16bit transfers ahc0: target 1 synchronous at 80.0MHz DT, offset = 0x3f usually hangs here, but sometimes if you pound on the keyboard at exactly the right moment, it will continue as in this case: pass0 at ahc0 bus 0 target 0 lun 0 pass0: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device pass0: Serial Number 3CC00ESN1048HMU7 pass0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled pass1 at ahc0 bus 0 target 1 lun 0 pass1: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device pass1: Serial Number 3CC00DZC10460HC7 pass1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled Creating DISK da0 Creating DISK da1 da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device da0: Serial Number 3CC00ESN1048HMU7 da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843671 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST318451LC 0002 Fixed Direct Access SCSI-3 device da1: Serial Number 3CC00DZC10460HC7 da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 17501MB (35843671 512 byte sectors:
Re: mdconfig/umount Fatal trap 12
Jens Schweikhardt [EMAIL PROTECTED] writes: hello, world\n with a system cvsupped June 6th I can reliably reproduce a [panic] when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Been there, done that. Got the patches and long thread(s) to prove it ;-). See message ID [EMAIL PROTECTED] Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) 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: mdconfig/umount Fatal trap 12
In message [EMAIL PROTECTED], Dima Dorfman write s: Jens Schweikhardt [EMAIL PROTECTED] writes: hello, world\n with a system cvsupped June 6th I can reliably reproduce a [panic] when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Been there, done that. Got the patches and long thread(s) to prove it ;-). See message ID [EMAIL PROTECTED] The idea here is that md(4) should be able to simulate a media which disappears with no warning so that people can debug problems related to (too) dynamic media transitions. If people think this is too much of a panic(8) implementation we can hide this behaviour behind a -JUSTDOIT! option. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: It seems your argument to disallow null symlinks got somehow taken as an argument to disallow all invalid symlinks then. To say it more clear: now I even not against -symlinks making ability, such strings are valid per POSIX after all, as already noticed in this discussion. I am against _resolving_ them to illegal name (and to . in pathnames) which cause all errors that Bruce describe. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic for today -- dsp_clone+0xee after moused started
OK; this is a(nother) page fault while in kernel mode, but I suspect it's one I hadn't seen mentioned yet. The good news is that it is eminently reproducible. :-} Also, I was able to boot kernel.old OK, so hat should decrease the probability that the problem is (strictly) somewhere in userland. As usual (for me), this is on my laptop. Recent CVSup history: CVSup begin from cvsup14.freebsd.org at Fri Jun 15 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Fri Jun 15 04:07:33 PDT 2001 CVSup begin from cvsup14.freebsd.org at Sat Jun 16 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sat Jun 16 03:52:48 PDT 2001 CVSup begin from cvsup14.freebsd.org at Sun Jun 17 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun Jun 17 03:52:46 PDT 2001 (I had built each of -STABLE -CURRENT after each one, and booted each successfully (running at least a few things), save for today's -CURRENT. And yes, I always buildworld, kernel, installworld, mergemaster.) The first couple of lines are from the console log: Initial rc.i386 initialization: apm. Configuring syscons: blank_time moused. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc018fe1a stack pointer = 0x10:0xce5a4d40 frame pointer = 0x10:0xce5a4d5c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 363 (ln) kernel: type 12 trap, code =0 Stopped at dsp_clone+0xee: movl0xc(%ebx),%edx db trace dsp_clone(0,ce5a4dc4,3,ce5a44a8,c17ae818) at dsp_clone+0xee devfs_lookupx(ce5a4e24,c17ae018,1,0,cc36c760) at devfs_lookupx+0x2b1 devfs_lookup(ce5a4e24,cd233da0,ce5a4ed0,ce5a4ea8,cc36c760) at devfs_lookup+0x31 lookup(ce5a4ea8,cc36c87c,cc36c760,cc36c760,cc36c760) at lookup+0x291 namei(ce5a4ea8,cc36c87c,cc36c760,2,bfbffe65) at namei+0x177 lstat(cc36c760,ce5a4f80,bfbffdc4,bfbffe65,bfbffe5b) at lstat+0x41 syscall(2f,2f,2f,bfbffe5b,bfbffe65) at syscall+0x71d syscall_with_err_pushed() at syscall_with_err_pushed+0x1b db show locks exclusive (sleep mutex) Giant (0xc047eb20) locked @ /usr/src/sys/vm/vm_fault.c:213 db Now, back on 13 June, I had added another line to /etc/rc.devfs -- the line symlinking /dev/dsp0 to /dev/dsp; here are the lines I've added: # Setup DEVFS, ie permissions, links etc. # ln -fs /dev/ttyv0 /dev/vga ln -fs /dev/sysmouse /dev/mouse ln -fs /dev/mixer0 /dev/mixer ln -fs /dev/dsp0 /dev/dsp chmod a+r /dev/apm I note also that I tried looking at last week's -cvs-all (mailing list) archive, but I can't find it. I see today's (the start of this week's); I see weeks prior to last; just not last week. And I see last week's for (say) -current; no problem. Help? I'll try removing/commenting that last dsp line in /etc/rc.devfs just after sending this off Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic for today -- dsp_clone+0xee after moused started
Date: Sun, 17 Jun 2001 12:49:34 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] [Yes, I *do* talk (well, mumble) to myself dhw] Now, back on 13 June, I had added another line to /etc/rc.devfs -- the line symlinking /dev/dsp0 to /dev/dsp; here are the lines I've added: # Setup DEVFS, ie permissions, links etc. # ln -fs /dev/ttyv0 /dev/vga ln -fs /dev/sysmouse /dev/mouse ln -fs /dev/mixer0 /dev/mixer ln -fs /dev/dsp0 /dev/dsp chmod a+r /dev/apm I'll try removing/commenting that last dsp line in /etc/rc.devfs just after sending this off Yup; that seemed to help considerably: dhcp-135[1] uname -a FreeBSD dhcp-135.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #36: Sun Jun 17 10:08:02 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 This response was slightly delayed by an opportunity to test background fsck, though: I had got that far, then tried play sounds/gong.au I see the following in /var/log/messages: Jun 17 12:57:18 localhost /boot/kernel/kernel: an0: Ethernet address: 00:40:96:32:19:a9 Jun 17 12:57:18 localhost pccardd[219]: an0: Cisco Systems (340 Series Wireless LAN Adapter) inserted. Jun 17 12:57:28 localhost dhclient: New IP Address (an0): 172.16.8.135 Jun 17 12:57:28 localhost dhclient: New Subnet Mask (an0): 255.255.255.0 Jun 17 12:57:28 localhost dhclient: New Broadcast Address (an0): 172.16.8.255 Jun 17 12:57:28 localhost dhclient: New Routers: 172.16.8.1 Jun 17 12:57:28 localhost dhclient: New Hostname: dhcp-135.catwhisker.org Jun 17 12:57:28 localhost pccardd[219]: pccardd started Jun 17 13:03:26 localhost /boot/kernel/kernel: Jun 17 13:03:26 localhost /boot/kernel/kernel: Jun 17 13:03:26 localhost /boot/kernel/kernel: Fatal trap 12: page fault while in kernel mode Jun 17 13:03:26 localhost /boot/kernel/kernel: fault virtual address= 0xc Jun 17 13:03:26 localhost /boot/kernel/kernel: fault code = supervisor read, page not present Jun 17 13:03:26 localhost /boot/kernel/kernel: instruction pointer = 0x8:0xc018fe1a Jun 17 13:03:26 localhost /boot/kernel/kernel: stack pointer= 0x10:0xce6adc44 Jun 17 13:03:26 localhost /boot/kernel/kernel: frame pointer= 0x10:0xce6adc60 Jun 17 13:03:26 localhost /boot/kernel/kernel: code segment = base 0x0, limit 0xf, type 0x1b Jun 17 13:03:26 localhost /boot/kernel/kernel: = DPL 0, pres 1, def32 1, gran 1 Jun 17 13:03:26 localhost /boot/kernel/kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Jun 17 13:03:26 localhost /boot/kernel/kernel: current process = 684 (sox) Jun 17 13:03:26 localhost /boot/kernel/kernel: trap number = 12 Jun 17 13:03:26 localhost /boot/kernel/kernel: panic: page fault Jun 17 13:03:26 localhost /boot/kernel/kernel: Jun 17 13:03:26 localhost /boot/kernel/kernel: syncing disks... 14 14 panic: witness_restore: lock (sleep mutex) Giant not locked Jun 17 13:03:26 localhost /boot/kernel/kernel: Uptime: 5m18s Jun 17 13:03:26 localhost /boot/kernel/kernel: Jun 17 13:03:26 localhost /boot/kernel/kernel: dumping to dev ad0s3b, offset 1572992 Jun 17 13:03:26 localhost /boot/kernel/kernel: dump ata0: resetting devices .. panic: witness_save: lock (sleep mutex) Giant not locked Jun 17 13:03:26 localhost /boot/kernel/kernel: Uptime: 5m18s Jun 17 13:03:26 localhost /boot/kernel/kernel: Dump already in progress, bailing... Jun 17 13:03:26 localhost /boot/kernel/kernel: Automatic reboot in 15 seconds - press a key on the console to abort Jun 17 13:03:27 localhost /boot/kernel/kernel: Rebooting... Jun 17 13:03:27 localhost /boot/kernel/kernel: Copyright (c) 1992-2001 The FreeBSD Project. Jun 17 13:03:27 localhost /boot/kernel/kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jun 17 13:03:27 localhost /boot/kernel/kernel: The Regents of the University of California. All rights reserved. Jun 17 13:03:27 localhost /boot/kernel/kernel: FreeBSD 5.0-CURRENT #36: Sun Jun 17 10:08:02 PDT 2001 I think I'm going to send this off (and make sure the background fscks complete) before trying any more experiments. :-} Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic for today -- dsp_clone+0xee after moused started
On Sun, Jun 17, 2001 at 12:49:34PM -0700, David Wolfskill wrote: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code= supervisor read, page not present instruction pointer = 0x8:0xc018fe1a stack pointer = 0x10:0xce5a4d40 frame pointer = 0x10:0xce5a4d5c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 363 (ln) kernel: type 12 trap, code =0 Stopped atdsp_clone+0xee: movl0xc(%ebx),%edx db trace dsp_clone(0,ce5a4dc4,3,ce5a44a8,c17ae818) at dsp_clone+0xee devfs_lookupx(ce5a4e24,c17ae018,1,0,cc36c760) at devfs_lookupx+0x2b1 devfs_lookup(ce5a4e24,cd233da0,ce5a4ed0,ce5a4ea8,cc36c760) at devfs_lookup+0x31 lookup(ce5a4ea8,cc36c87c,cc36c760,cc36c760,cc36c760) at lookup+0x291 namei(ce5a4ea8,cc36c87c,cc36c760,2,bfbffe65) at namei+0x177 lstat(cc36c760,ce5a4f80,bfbffdc4,bfbffe65,bfbffe5b) at lstat+0x41 syscall(2f,2f,2f,bfbffe5b,bfbffe65) at syscall+0x71d syscall_with_err_pushed() at syscall_with_err_pushed+0x1b db show locks exclusive (sleep mutex) Giant (0xc047eb20) locked @ /usr/src/sys/vm/vm_fault.c:213 db I see that, too. It happens when /dev/dsp is accessed (touch /dev/dsp is sufficient). I couldn't get a dump, but from looking at it in ddb and snd_pcm.ko, it is the first line in this code: 9e70 dsp_clone: [...] 9f59: 0f b6 47 0c movzbl 0xc(%edi),%eax 9f5d: c1 e0 10shl$0x10,%eax 9f60: 83 e2 0fand$0xf,%edx 9f63: c1 e2 04shl$0x4,%edx 9f66: 09 d0 or %edx,%eax 9f68: 0b 45 f8or 0xfff8(%ebp),%eax which correspondends to src/sys/dev/sound/pcm/dsp.c:1031 : pdev = makedev(SND_CDEV_MAJOR, PCMMKMINOR(unit, devtype, d-defaultchan++)); specifically, the d-defaultchan. When this panic occurs, both edi and eax are zero. Bye, Philipp -- http://www.uni-karlsruhe.de/~un1i/ (,.) \\\@@ ) \= ) cc_|\_,^ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: convert libgmp to a port?
On Sun, Jun 17, 2001 at 06:22:56PM +0300, Giorgos Keramidas wrote: On Sat, Jun 16, 2001 at 11:38:45PM -0700, Peter Wemm wrote: It should not be too hard to have build a lightweight 'libbignum' that is extracted from the openssl sources and make that available in the base system. It would not be hard to convert the lib*mp consumers to use the libbignum (libbn, -lbn ?) and then we can get rid of it. telnet* should never have used libmp in the first place, it should have used libcrypto/bignum. chkey/newkey/keyserv are using libmp for diffie-helmann key exchange. (just large integer multiplication). It should be really easy to convert those three. Since there are a few things that are using libgmp (and I missed them in my quick search through the sources), no I would not prefer removing libgmp and making a new, probably buggier, libbignum that will replace our current libgmp. If we do need some of the functionality of libgmp in the base-system, then we really should import some newer version of libgmp, instead of trying to make our own new library. I dont really like reinventing wheels :) libbn is already part of OpenSSH; it's a trivial matter to make it into a standalone library. In other words, we already include two functionally equivalent bignum libraries in FreeBSD, so one of them should go. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: : It seems your argument to disallow null symlinks got somehow taken : as an argument to disallow all invalid symlinks then. : : :To say it more clear: now I even not against -symlinks making ability, :such strings are valid per POSIX after all, as already noticed in this :discussion. I am against _resolving_ them to illegal name (and to . :in pathnames) which cause all errors that Bruce describe. : :-- :Andrey A. Chernov This is a reasonable distinction to make. If someone actually tried to open() a 'd symlink an argument can be made to return a specific error rather then trying to resolve it. I'm not sure it's worth it, though. It just doesn't come up that often and there are a thousand other ways you can hogtie yourself in the system that takes less effort. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote: rather then trying to resolve it. I'm not sure it's worth it, though. It just doesn't come up that often and there are a thousand other ways you can hogtie yourself in the system that takes less effort. It worth. It cause real 'make install' errors in some cases. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: convert libgmp to a port?
On Sun, Jun 17, 2001 at 01:51:56PM -0700, Kris Kennaway wrote: libbn is already part of OpenSSH; it's a trivial matter to make it into a standalone library. In other words, we already include two functionally equivalent bignum libraries in FreeBSD, so one of them should go. I couldn't agree more :) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote: : : rather then trying to resolve it. I'm not sure it's worth it, though. : It just doesn't come up that often and there are a thousand other ways you : can hogtie yourself in the system that takes less effort. : :It worth. It cause real 'make install' errors in some cases. : :-- :Andrey A. Chernov What cases? In all my years of programming I've never once 'accidently' created an empty symlink. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: What cases? In all my years of programming I've never once 'accidently' created an empty symlink. See initial Bruce comments. Sometimes when 'make hierarchy' step is missing, intermediate result of 'make install' can't be undone easily. I hit this several times because my area (l10n) is symlink-rich. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: What cases? In all my years of programming I've never once 'accidently' created an empty symlink. The next example is fts-like activity - wrong final destination appearse which is dangerous for 'rm'. I.e. in some situation you can remove something like /kernel via specially constructed (by bad guy) empty simlink. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
: :On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: : What cases? In all my years of programming I've never once 'accidently' : created an empty symlink. : :The next example is fts-like activity - wrong final destination :appearse which is dangerous for 'rm'. I.e. in some situation you can :remove something like /kernel via specially constructed (by bad guy) empty :simlink. : :-- :Andrey A. Chernov :http://ache.pp.ru/ I'm sorry, I don't understand... what does this have to do with an empty symlink verses a symlink containing something else? 'rm' does not traverse symlinks. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
: :On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote: : : What cases? In all my years of programming I've never once 'accidently' : created an empty symlink. : :See initial Bruce comments. Sometimes when 'make hierarchy' step is :missing, intermediate result of 'make install' can't be undone easily. I :hit this several times because my area (l10n) is symlink-rich. : :-- :Andrey A. Chernov :http://ache.pp.ru/ If something in the build is creating empty symlinks under certain circumstances, that something should be fixed. The problem isn't ln -s. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic for today -- dsp_clone+0xee after moused started
Date: Mon, 18 Jun 2001 00:33:18 +0200 From: Philipp Mergenthaler [EMAIL PROTECTED] Revision 1.39 of dsp.c doesn't fix this panic. 1.40 (along with associated changes to sndstat.c, sound.c, sound.h) appears to work OK for me -- thanks! (Hmmm... I just noticed another round of changes I'll try those, too) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 17:01:08 -0700, Matt Dillon wrote: I'm sorry, I don't understand... what does this have to do with an empty symlink verses a symlink containing something else? 'rm' does not traverse symlinks. I not mean 'rm' literally. Read Bruce's comment about how fake names constructed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 17:26:16 -0700, Matt Dillon wrote: If something in the build is creating empty symlinks under certain circumstances, that something should be fixed. The problem isn't ln -s. There is nothing to fix. Sometimes 'make install' instead 'make installworld' typed can produce this. Of course, install procedure can be complicated to make it foolprof, but I think the system must be fixed instead to not resolve illegal names. It is not good idea to produce workarounds of illegal names out of the system. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Workaround for PS/2 mouse problems with recent -current
Commenting out hint.atkbd.0.* and hint.psm.0.* fixed the problem that others reported. Little investigation showed that the new resource_find() function in kern/subr_bus.c finds two atkbd0 and two psm0, one of each from kern_envp, and the other one from static_hints; no wildcard matches were involved. I'll leave the real solution for the more kernel-clueful here. \Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
:There is nothing to fix. Sometimes 'make install' instead 'make :installworld' typed can produce this. Of course, install procedure can be :complicated to make it foolprof, but I think the system must be fixed :instead to not resolve illegal names. It is not good idea to :produce workarounds of illegal names out of the system. : :-- :Andrey A. Chernov Ok, I took a look at Bruce's original example, which is: ln -s X If you were to then do something like ls -la X/. you would get the root directory, and ls -la X/ tries to list the current directory, and cp -r X Y tries to recursively copy the current directory, and fails. I think we can safely disallow path lookups going through empty symlinks (i.e. at the time of the open(), lstat(), etc...), but we should not go changing the ln command or the symlink() system call. In regards to Bruce's second example: $ rm -f foo $ ln -s /nonesuch foo $ cp foo bar Well, ok, if what the symlink points to does not exist 'cp' goes and copies the symlink instead. This seems harmless to me. I still don't see how any of this is a security issue, though. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
At 2:28 PM -0700 6/17/01, Matt Dillon wrote: :On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: : It seems your argument to disallow null symlinks got somehow taken : as an argument to disallow all invalid symlinks then. : : :To say it more clear: now I even not against -symlinks making ability, :such strings are valid per POSIX after all, as already noticed in this :discussion. I am against _resolving_ them to illegal name (and to . :in pathnames) which cause all errors that Bruce describe. : :-- :Andrey A. Chernov This is a reasonable distinction to make. If someone actually tried to open() a 'd symlink an argument can be made to return a specific error rather then trying to resolve it. I'm not sure it's worth it, though. I think that it's reasonable to just make it a specific error, and thus end this thread. No harm will come of making it a specific error on open, and it will address the problems mentioned earlier. When I say this, I assume that the only change to make is how any 'open' or 'stat' call will handle null symlinks. If I am reading Andrey correctly, there will be no change to the 'ln' command or the symlink() system routine. Assuming this is true, is there any downside to making open() and stat() return an error for a null symlink? I generally prefer returning an error at the earliest point it can be determined to be an error, and thus I think it IS worth it to make this an error at open() or stat() time. I see no benefit in letting those succeed only to have some strange error occur in later processing. I do not care if this is or is not a security error, I am talking about saving someone time when debugging a side-effect of having a null symlink. I think that's my 2 cents on this issue, although later on I may find I'll want these 2 cents back and will contribute a different 2 cents. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 18:00:06 -0700, Matt Dillon wrote: I think we can safely disallow path lookups going through empty symlinks (i.e. at the time of the open(), lstat(), etc...), but we should not go changing the ln command or the symlink() system call. This is exact the same thing as I suggest. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: convert libgmp to a port?
Garrett Wollman [EMAIL PROTECTED] writes: On Sat, 16 Jun 2001 23:38:45 -0700, Peter Wemm [EMAIL PROTECTED] said: telnet* should never have used libmp in the first place, Yes, it should have, since telnet is historic BSD software and libmp is the historic BSD arbitrary-precision-math library. But telnet in historic BSD didn't have sra or any other authentication mechanism that uses libmp. Or are you saying that we cannot change `historical BSD software'? /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sun, Jun 17, 2001 at 21:16:24 -0400, Garance A Drosihn wrote: When I say this, I assume that the only change to make is how any 'open' or 'stat' call will handle null symlinks. If I am reading Andrey correctly, there will be no change to the 'ln' command or the symlink() system routine. Yes. I generally prefer returning an error at the earliest point it can be determined to be an error, and thus I think it IS worth it to make this an error at open() or stat() time. I see no benefit in letting those succeed only to have some strange error occur in later processing. Yes. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Heh. We came up with virtually the same patch at the same time! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [CFR] latest KAME merge into FreeBSD
On Mon, 04 Jun 2001 19:20:36 +0900 (JST),
Hajimu UMEMOTO [EMAIL PROTECTED] said:
I just put the patch for merging latest KAME into FreeBSD:
http://www.imasy.or.jp/~ume/ipv6/test/freebsd5-kame20010528-20010604.diff.gz
This is based on KAME snap 20010528 and against 5-CURRENT of Jun 2.
There are many many changes since last KAME merge (2701).
Please review it.
Thanks for the effort. Could you apply the following patch? The fix
is not so serious for most users, but should be important for
nomadic users who use IPv6 temporary addresses (for privacy extension).
JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
Index: nd6_rtr.c
===
RCS file: /cvsroot/kame/kame/kame/sys/netinet6/nd6_rtr.c,v
retrieving revision 1.119
retrieving revision 1.121
diff -c -r1.119 -r1.121
*** nd6_rtr.c 2001/06/04 09:07:28 1.119
--- nd6_rtr.c 2001/06/18 03:10:25 1.121
***
*** 1,4
! /*$KAME: nd6_rtr.c,v 1.119 2001/06/04 09:07:28 keiichi Exp $ */
/*
* Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
--- 1,4
! /*$KAME: nd6_rtr.c,v 1.121 2001/06/18 03:10:25 jinmei Exp $ */
/*
* Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
***
*** 1903,1908
--- 1903,1909
int
in6_tmpifadd(ia0, forcegen)
const struct in6_ifaddr *ia0; /* corresponding public address */
+ int forcegen;
{
struct ifnet *ifp = ia0-ia_ifa.ifa_ifp;
struct in6_ifaddr *newia;
***
*** 2001,2006
--- 2002,2017
}
newia-ia6_ndpr = ia0-ia6_ndpr;
newia-ia6_ndpr-ndpr_refcnt++;
+
+ /*
+* A newly added address might affect the status of other addresses.
+* XXX: when the temporary address is generated with a new public
+* address, the onlink check is redundant. However, it would be safe
+* to do the check explicitly everywhere a new address is generated,
+* and, in fact, we surely need the check when we create a new
+* temporary address due to deprecation of an old temporary address.
+*/
+ pfxlist_onlink_check();
return(0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])
On Sun, 17 Jun 2001, Matt Dillon wrote:
Ok, this patch should do it. For review. I've made it return ENOENT,
which is the same error that is returned when you try to open an empty
path (e.g. open(, ...)).
(Note: This is unrelated to Bruce's second issue with 'cp' copying
symlinks that don't exist, which is a cp-specific).
If nobody has any objections I will commit this to -current on wednesday
and MFC it next saturday.
Index: vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.2
diff -u -r1.38.2.2 vfs_lookup.c
--- vfs_lookup.c 2001/05/20 12:11:57 1.38.2.2
+++ vfs_lookup.c 2001/06/18 01:39:46
@@ -200,6 +200,12 @@
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
+ if (linklen == 0) {
+ if (ndp-ni_pathlen 1)
+ zfree(namei_zone, cp);
+ error = ENOENT;
+ break;
+ }
if (linklen + ndp-ni_pathlen = MAXPATHLEN) {
if (ndp-ni_pathlen 1)
zfree(namei_zone, cp);
NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
I like it, except it seems to be incompatible with POSIX.1-200x.
The bug that stat(2) on a null symlink classifies the target of the symlink
as a directory is caused by resolving the pathname to and then not
returning ENOENT in namei(). tends to be interpreted as . unless
it is specially disallowed, and that's what happens here. is only
disallowed for the unresolved pathname. Since the bug is in namei(), it
affects all syscalls that deal with pathnames. E.g., you can open()
null symlinks; this is equivalent to opening ..
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
