m4 leaving /tmp/m4* directories
After m4 has been changed to do its temporary work in a subdirectory, "make world" leaves a lot of /tmp/m4* directories behind. This patch fix it for me. It is not protected by a "#ifndef vms" though. I don't know if vms has rmdir() or not and I'm not sure if we care about it. John -- John Hay -- [EMAIL PROTECTED] Index: usr.bin/m4/main.c === RCS file: /home/ncvs/src/usr.bin/m4/main.c,v retrieving revision 1.8 diff -u -r1.8 main.c --- usr.bin/m4/main.c 2000/11/22 11:09:30 1.8 +++ usr.bin/m4/main.c 2001/02/20 05:58:02 @@ -227,9 +227,10 @@ (void) remove(m4temp); #else (void) unlink(m4temp); - (void) rmdir(m4dir); #endif } + if (m4dir != NULL) + (void) rmdir(m4dir); return 0; } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subsribe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: m4 leaving /tmp/m4* directories
On Sun, 25 Feb 2001, John Hay wrote: After m4 has been changed to do its temporary work in a subdirectory, "make world" leaves a lot of /tmp/m4* directories behind. This patch fix it for me. It is not protected by a "#ifndef vms" though. I don't know if vms has rmdir() or not and I'm not sure if we care about it. I think remove() is supposed to work for all types of files. It is documented to work for directories in FreeBSD. Using remove() in both cases can't break the vms case more than it already is (the previous commit didn't attempt to maintain it). Index: usr.bin/m4/main.c === RCS file: /home/ncvs/src/usr.bin/m4/main.c,v retrieving revision 1.8 diff -u -r1.8 main.c --- usr.bin/m4/main.c 2000/11/22 11:09:30 1.8 +++ usr.bin/m4/main.c 2001/02/20 05:58:02 @@ -227,9 +227,10 @@ (void) remove(m4temp); #else (void) unlink(m4temp); - (void) rmdir(m4dir); #endif } + if (m4dir != NULL) + (void) rmdir(m4dir); return 0; } m4dir is known to be non-NULL here. If it would be NULL, then we have already dumped core for asprintf()'ing it after not checking the value returned by mkdtemp(). We also follow the null pointer after (void)ing errors in asprintf(). Cleaning up is also broken in killdev(). Cleaning up doesn't seem to have ever been implemented in the signal handler. onintr() has the usual bugs, but it doesn't remove any files. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Giving up on buffers
Matt Dillon [EMAIL PROTECTED] writes: (2) the I/O for the buffer synchronization is initiated but interrupts are winding up being disabled by the halt code due to holding Giant and not sleeping (more likely). That all I can think of. We've hit the interrupt disablement problem before in -current, it's probably something simliar. Sounds likely. On my laptop, the "giving up on n buffers" message is usually accompanied by an ata0 timeout. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree 4.0 broken by libc changes ?
Daniel, I don't know, what port builds libGL.so.1? Something has to link in the threads library... Yep, XFree86 libs should be linked against -lc_r, I got this working with this. It's still broken in FreeBSD ports, all GL dependent programms are broken for CURRENT at the moment. I've another issue now: /usr/local/bin/dcopidl ./konq_undo.h konq_undo.kidl || rm -f konq_undo.kidl /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol "_flockfile" /usr/local/bin/dcopidl2cpp --c++-suffix cc --no-stub konq_undo.kidl /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol "_flockfile This while I'm trying to build kdebase2 from ports. You've got an idea ? # objdump --dynamic-syms /usr/lib/libc_r.so.5 | grep _flockfile 9068 gDF .text 0040 _flockfile_debug D *UND* _flockfile and right, it's undefined there ... Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dump(8) segfaults
This is on alpha--does anybody see this on i386 as well? naddy@kemoauc[~] dump 0af /dev/null /dev/da0a DUMP: Date of this level 0 dump: Sun Feb 25 15:33:49 2001 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0a (/) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 67655 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: SIGSEGV: ABORTING! DUMP: SIGSEGV: ABORTING! DUMP: SIGSEGV: ABORTING! DUMP: SIGSEGV: ABORTING! DUMP: SIGSEGV: ABORTING! Segmentation fault -current as of Feb 20. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree 4.0 broken by libc changes ?
Hi, konq_undo.kidl /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol "_flockfile" /usr/local/bin/dcopidl2cpp --c++-suffix cc --no-stub konq_undo.kidl /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol "_flockfile Sorry, fixed this with recompling qt. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VESA crash + softupdt inconsistency
World is 18 Feb 2001 Kernel is 23 Feb 2001 vidcontrol -g 100x37 VESA_800x600 (while building another kernel) made machine hang, beeping continuously, tcp/ip stack was down, ctrl-alt-del unusable. Plugged power off (forgot to ask for ddb. still a freebsd newbie...) At boot, had an 'UNEXPECTED SOFT UPDATE INCONSISTENCY' on /usr (which had softupdates turned on + noatime). manual fsck corrected about 200 summary informations. Attachment: log with the error, the fsck output and dmesg output (Apologies in advance, if a 14Kb attachment is inapropriate for the list) Cheers, --fred System is from 18 Feb 2001 Kernel is from 23 Feb 2001 Boot log: ad0: 39082MB Maxtor 54098H8 [79406/16/63] at ata0-master UDMA66 acd0: DVD-ROM ASUS DVD-ROM E608 at ata0-slave using UDMA33 Waiting 10 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s4a WARNING: / was not properly dismounted swapon: adding /dev/ad0s4b as swap device Automatic boot in progress... /dev/ad0s4a: 2402 files, 45564 used, 4019 free (267 frags, 469 blocks, 0.5% frag mentation) cd0 at ahc0 bus 0 target 5 lun 0 cd0: YAMAHA CRW8424S 1.0f Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 15) cd0: cd present [1 x 2048 byte records] /dev/ad0s4f: INCORRECT BLOCK COUNT I=2595990 (2256 should be 208) (CORRECTED) /dev/ad0s4f: UNALLOCATED I=2937264 OWNER=root MODE=100644 /dev/ad0s4f: SIZE=7872 MTIME=Feb 25 17:49 2001 /dev/ad0s4f: FILE=/obj/usr/src/sys/AGLAE/modules/usr/src/sys/modules/vpo/immio.o /dev/ad0s4f: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s4e: 966 files, 6601 used, 13214 free (230 frags, 1623 blocks, 1.2% frag mentation) THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/ad0s4f (/usr) Automatic file system check failed . . . help! Enter full pathname of shell or RETURN for /bin/sh: # fsck /dev/ad0s4f ** /dev/ad0s4f ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y ALLOCATED FRAG 926933 MARKED FREE ALLOCATED FRAG 926934 MARKED FREE ALLOCATED FRAG 927080 MARKED FREE ALLOCATED FRAG 927081 MARKED FREE ALLOCATED FRAG 927082 MARKED FREE ALLOCATED FRAG 927083 MARKED FREE ALLOCATED FRAG 927084 MARKED FREE ALLOCATED FRAG 927085 MARKED FREE ALLOCATED FRAG 927086 MARKED FREE ALLOCATED FRAG 927087 MARKED FREE ALLOCATED FRAG 927104 MARKED FREE ALLOCATED FRAG 927105 MARKED FREE ALLOCATED FRAG 927106 MARKED FREE ALLOCATED FRAG 927107 MARKED FREE ALLOCATED FRAG 927108 MARKED FREE ALLOCATED FRAG 927109 MARKED FREE ALLOCATED FRAG 927110 MARKED FREE ALLOCATED FRAG 927112 MARKED FREE ALLOCATED FRAG 927113 MARKED FREE ALLOCATED FRAG 927114 MARKED FREE ALLOCATED FRAG 927115 MARKED FREE ALLOCATED FRAG 927116 MARKED FREE ALLOCATED FRAG 927117 MARKED FREE ALLOCATED FRAG 927118 MARKED FREE ALLOCATED FRAG 927119 MARKED FREE ALLOCATED FRAG 927120 MARKED FREE ALLOCATED FRAG 927121 MARKED FREE ALLOCATED FRAG 927122 MARKED FREE ALLOCATED FRAG 927123 MARKED FREE ALLOCATED FRAG 927124 MARKED FREE ALLOCATED FRAG 927125 MARKED FREE ALLOCATED FRAG 927126 MARKED FREE ALLOCATED FRAG 927127 MARKED FREE BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y ALLOCATED INODE 238340 MARKED FREE ALLOCATED FRAG 4226888 MARKED FREE ALLOCATED FRAG 4226889 MARKED FREE ALLOCATED FRAG 4226890 MARKED FREE ALLOCATED FRAG 4226891 MARKED FREE ALLOCATED FRAG 4226892 MARKED FREE ALLOCATED FRAG 4226893 MARKED FREE ALLOCATED FRAG 4226894 MARKED FREE ALLOCATED INODE 2595976 MARKED FREE ALLOCATED INODE 2595977 MARKED FREE ALLOCATED INODE 2595978 MARKED FREE ALLOCATED INODE 2595979 MARKED FREE ALLOCATED INODE 2595980 MARKED FREE ALLOCATED INODE 2595981 MARKED FREE ALLOCATED INODE 2595982 MARKED FREE ALLOCATED INODE 2595983 MARKED FREE ALLOCATED INODE 2595984 MARKED FREE ALLOCATED INODE 2595985 MARKED FREE ALLOCATED INODE 2595986 MARKED FREE ALLOCATED INODE 2595987 MARKED FREE ALLOCATED INODE 2595988 MARKED FREE ALLOCATED INODE 2595989 MARKED FREE ALLOCATED INODE 2595990 MARKED FREE ALLOCATED INODE 2595991 MARKED FREE ALLOCATED INODE 2595992 MARKED FREE ALLOCATED INODE 2595993 MARKED FREE ALLOCATED INODE 2595994 MARKED FREE ALLOCATED INODE 2595995 MARKED FREE ALLOCATED INODE 2595996 MARKED FREE ALLOCATED FRAG 10752925 MARKED FREE ALLOCATED FRAG 10752926 MARKED FREE ALLOCATED FRAG 10945763 MARKED FREE ALLOCATED FRAG 10945764 MARKED FREE ALLOCATED FRAG 10945765 MARKED FREE ALLOCATED FRAG 10945766 MARKED FREE ALLOCATED FRAG 10945767 MARKED FREE ALLOCATED FRAG 11212226 MARKED FREE ALLOCATED FRAG 11212227 MARKED FREE ALLOCATED FRAG 11212228 MARKED FREE ALLOCATED FRAG 11212229 MARKED FREE ALLOCATED FRAG 11212230 MARKED FREE ALLOCATED FRAG 11212672 MARKED FREE ALLOCATED FRAG 11212673 MARKED
some proposals about nfsd(8)
Hi, nfsd.c has the following lines: (void)signal(SIGQUIT, SIG_IGN); (void)signal(SIGTERM, SIG_IGN); So nfsd(8) can only be killed by -9. Does this make sense ? Unregistering withing rpcbind or portmap is not possible, so one has to kill portmap(8) or rpcbind(8) and restart all the rpc services which had registered themself within portmapper. Very very bad. This also rises some questions about 'nfsd -r'. This flag is used to reregister an existing nfsd within portmapper or rpcbind. But since we use 'nfsd -h' to allow nfsd to bind to one or more IP's, it's broken for some part cause the wrong addresses get registered. It's better to kill nfsd and restart it. So my first proposal is to remove the SIG_IGN lines and adding a signal handler for unregistering nfs within portmapper or rpcbind. Second, I'd like to have this 'nfsd -r' removed, cause it's broken in the concept anyway and useless. Kill nfsd and restart does the same, and the binding is done the right way. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree 4.0 broken by libc changes ?
On Sun, 25 Feb 2001, Martin Blapp wrote: Daniel, I don't know, what port builds libGL.so.1? Something has to link in the threads library... Yep, XFree86 libs should be linked against -lc_r, I got this working with this. It's still broken in FreeBSD ports, all GL dependent programms are broken for CURRENT at the moment. I've another issue now: /usr/local/bin/dcopidl ./konq_undo.h konq_undo.kidl || rm -f konq_undo.kidl /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol "_flockfile" /usr/local/bin/dcopidl2cpp --c++-suffix cc --no-stub konq_undo.kidl /usr/libexec/ld-elf.so.1: /usr/lib/libc_r.so.5: Undefined symbol "_flockfile This while I'm trying to build kdebase2 from ports. You've got an idea ? # objdump --dynamic-syms /usr/lib/libc_r.so.5 | grep _flockfile 9068 gDF .text 0040 _flockfile_debug D *UND* _flockfile Right, _flockfile is in libc.so.5 now. It should be picked up if the application is also linked with libc.so.5, I think. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some proposals about nfsd(8)
* Martin Blapp [EMAIL PROTECTED] [010225 11:44] wrote: Hi, nfsd.c has the following lines: (void)signal(SIGQUIT, SIG_IGN); (void)signal(SIGTERM, SIG_IGN); So nfsd(8) can only be killed by -9. Does this make sense ? Unregistering withing rpcbind or portmap is not possible, so one has to kill portmap(8) or rpcbind(8) and restart all the rpc services which had registered themself within portmapper. Very very bad. Well, I would check the CVS logs to see why it had been done, if it came like that from 4.4BSD then we should change it, but otherwise consider why it was added. This also rises some questions about 'nfsd -r'. This flag is used to reregister an existing nfsd within portmapper or rpcbind. But since we use 'nfsd -h' to allow nfsd to bind to one or more IP's, it's broken for some part cause the wrong addresses get registered. It's better to kill nfsd and restart it. So my first proposal is to remove the SIG_IGN lines and adding a signal handler for unregistering nfs within portmapper or rpcbind. Second, I'd like to have this 'nfsd -r' removed, cause it's broken in the concept anyway and useless. Kill nfsd and restart does the same, and the binding is done the right way. I'd like to kill 'nfsd -r' however it makes more sense to fix -r so that it works with -h than to just remove the functionality. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some proposals about nfsd(8)
: : :Hi, : :nfsd.c has the following lines: : :(void)signal(SIGQUIT, SIG_IGN); :(void)signal(SIGTERM, SIG_IGN); : :So nfsd(8) can only be killed by -9. Does this make :sense ? Unregistering withing rpcbind or portmap is :not possible, so one has to kill portmap(8) or rpcbind(8) :and restart all the rpc services which had registered :themself within portmapper. Very very bad. nfsd sits in the kernel most of the time. It needs to ignore SIGTERM in order to stay alive as long as possible during a shutdown, otherwise loopback mounts will not be able to unmount. You do not have to kill portmap to restart nfsd. Nfsd sits on a known port, all you need to do is restart nfsd if you've killed it. :This also rises some questions about 'nfsd -r'. This :flag is used to reregister an existing nfsd within nfsd -r is used if you already have nfsd's running but somehow unregistered the nfs service from the portmapper. For example, if you killed the portmapper and restarted it. nfsd -r simply reregisters the service that is already running and then exits. :portmapper or rpcbind. But since we use 'nfsd -h' :to allow nfsd to bind to one or more IP's, it's :broken for some part cause the wrong addresses get :registered. It's better to kill nfsd and restart :it. The -h issue has nothing to do with the portmapper. The portmapper does not map IP addresses, only ports. -h is necessary when you have a multi-homed machine and wish to allow UDP NFS mounts. In order to UDP NFS mounts to work, the socket must be bound to a particular IP address or the NFS replies from the server may come from the wrong host. :So my first proposal is to remove the SIG_IGN lines and :adding a signal handler for unregistering nfs within :portmapper or rpcbind. That will not solve any real problem and can screw up a shutdown sequence. :Second, I'd like to have this 'nfsd -r' removed, cause :it's broken in the concept anyway and useless. Kill nfsd and :restart does the same, and the binding is done the right way. : :Martin There's nothing wrong with nfsd -r. It's there in case someone decides they need to kill and restart the portmapper but don't want to unnecessarily interrupt existing nfsd connections (e.g. TCP NFS mounts). -Matt :Martin Blapp, [EMAIL PROTECTED] : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some proposals about nfsd(8)
Hi Matt, thank you for you mail. nfsd sits in the kernel most of the time. It needs to ignore SIGTERM in order to stay alive as long as possible during a shutdown, otherwise loopback mounts will not be able to unmount. ok, added a comment about this. nfsd -r is used if you already have nfsd's running but somehow unregistered the nfs service from the portmapper. For example, if you killed the portmapper and restarted it. nfsd -r simply reregisters the service that is already running and then exits. that's clear. but why I get such output ? # nfsd -h localhost (and output from rpcinfo(8)) 132udp 127.0.0.1.8.1 nfssuperuser 133udp 127.0.0.1.8.1 nfssuperuser 132udp6 ::1.8.1nfssuperuser 133udp6 ::1.8.1nfssuperuser and if it's just started normal: # nfsd(8) and (and output from rpcinfo(8)) 132udp 0.0.0.0.8.1nfssuperuser 133udp 0.0.0.0.8.1nfssuperuser 132udp6 ::.8.1 nfssuperuser 133udp6 ::.8.1 nfssuperuser rpcbind(8) has registered it with the complete address. Is this visible output only and it listen to ports only or does this also includes binding to some interface ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current SMP kernel won't build
I haven't been able to build a SMP kernel for a day. I just did a make world and tried again, no luck I keep getting this error: linking kernel.debug cam_periph.o: In function `cam_periph_mapmem': /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xa42): undefined reference to `_mtx_assert' cam_periph.o: In function `cam_periph_unmapmem': /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xc02): undefined reference to `_mtx_assert' /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xd86): undefined reference to `_mtx_assert' /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xeee): undefined reference to `_mtx_assert' yarrow.o: In function `reseed': /usr/src/sys/compile/pro2/../../dev/random/yarrow.c(.text+0x54f): undefined reference to `_mtx_assert' yarrow.o:/usr/src/sys/compile/pro2/../../dev/random/yarrow.c:417: more undefined references to `_mtx_assert' follow *** Error code 1 Stop in /usr/src/sys/compile/pro2 Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP kernel won't build
cam_periph.o: In function `cam_periph_mapmem': /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xa42): undefined refe rence to `_mtx_assert' Try putting, options INVARIANT_SUPPORT in your kernel config. I think jhb recently made mtx_assert conditional on that option. Either that, or take out "options INVARIANTS". Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP kernel won't build
At 02:28 PM 2/25/2001 -0800, you wrote: cam_periph.o: In function `cam_periph_mapmem': /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xa42): undefined refe rence to `_mtx_assert' Try putting, options INVARIANT_SUPPORT in your kernel config. I think jhb recently made mtx_assert conditional on that option. Either that, or take out "options INVARIANTS". Dima Dorfman [EMAIL PROTECTED] That did it Thanks Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some proposals about nfsd(8)
:ok, added a comment about this. : : nfsd -r is used if you already have nfsd's : running but somehow unregistered the nfs service : from the portmapper. For example, if you killed : the portmapper and restarted it. nfsd -r simply : reregisters the service that is already running : and then exits. : :that's clear. but why I get such output ? : :# nfsd -h localhost (and output from rpcinfo(8)) :132udp 127.0.0.1.8.1 nfssuperuser :133udp 127.0.0.1.8.1 nfssuperuser :132udp6 ::1.8.1nfssuperuser :133udp6 ::1.8.1nfssuperuser : :and if it's just started normal: : :# nfsd(8) and (and output from rpcinfo(8)) :132udp 0.0.0.0.8.1nfssuperuser :133udp 0.0.0.0.8.1nfssuperuser :132udp6 ::.8.1 nfssuperuser :133udp6 ::.8.1 nfssuperuser : :Martin : :... If you run nfsd without a -h argument, it binds to INADDR_ANY which means that it can accept packets from any interface. However, if you have more then one interface this will break UDP mounts because the reply packet may not be returned from the same IP address that it was sent to. What argument are you passing to rpcinfo? All I get is: earth:/home/dillon rpcinfo -p program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 153 udp 1023 mountd 153 tcp 1023 mountd 151 udp 1023 mountd 151 tcp 1023 mountd 132 udp 2049 nfs 133 udp 2049 nfs 1000241 udp 1011 status 1000241 tcp 1022 status 132 tcp 2049 nfs 133 tcp 2049 nfs The portmapper has no concept of IP address bindings, only port bindings. It understands program, version, protocol, and port, and that's it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Giving up on buffers
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Matt Dillon [EMAIL PROTECTED] writes: : (2) the I/O for the buffer synchronization is initiated but interrupts : are winding up being disabled by the halt code due to holding Giant : and not sleeping (more likely). That all I can think of. We've hit : the interrupt disablement problem before in -current, it's probably : something simliar. : : Sounds likely. On my laptop, the "giving up on n buffers" message is : usually accompanied by an ata0 timeout. Just FYI: ata isn't printing a timeout for me. However, I have had several panics with the lpt problem which freeze the system hard in the syncing buffers. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP kernel won't build
What on *earth* are you all referring to? With current top of tree I get QUARM:253: unknown option "INVARIANT_SUPPORT" On Sun, 25 Feb 2001, Manfred Antar wrote: At 02:28 PM 2/25/2001 -0800, you wrote: cam_periph.o: In function `cam_periph_mapmem': /usr/src/sys/compile/pro2/../../cam/cam_periph.c(.text+0xa42): undefined refe rence to `_mtx_assert' Try putting, options INVARIANT_SUPPORT in your kernel config. I think jhb recently made mtx_assert conditional on that option. Either that, or take out "options INVARIANTS". Dima Dorfman [EMAIL PROTECTED] That did it Thanks Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == 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: Current SMP kernel won't build
On Sun, Feb 25, 2001 at 03:48:36PM -0800, Matthew Jacob wrote: What on *earth* are you all referring to? With current top of tree I get QUARM:253: unknown option "INVARIANT_SUPPORT" You're a few days back from the top. It was removed briefly then reappeared. Kris PGP signature
Re: Current SMP kernel won't build
What on *earth* are you all referring to? With current top of tree I get QUARM:253: unknown option "INVARIANT_SUPPORT" src/sys/conf/options: revision 1.256 date: 2001/02/24 19:03:18; author: jhb; state: Exp; lines: +2 -1 Add back in INVARIANT_SUPPORT and expand the comments in NOTES about it to include the reasoning Eivind justifiably thwapped me over the head with. ... revision 1.254 date: 2001/02/22 10:03:05; author: jhb; state: Exp; lines: +1 -2 Now that zerror() and SPLASSERT() have been laid to rest, INVARIANT_SUPPORT is no longer needed. R.I.P. Looks like you have a tree somewhere between those two commits. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP kernel won't build
sorry.. I have a nightly script that updates, but it fell over (silently) on the 23rd... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Scheduler panic
This is on a UP system.
Kris
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4767744
initial pcb at 3c9740
panicstr: from debugger
panic messages:
---
panic: runq_add: proc 0xca466420 (more) not SRUN
panic: from debugger
Uptime: 3h39m42s
dumping to dev #da/0x20001, offset 262144
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:476
476 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:476
#1 0xc01b0c3c in boot (howto=260) at ../../kern/kern_shutdown.c:319
#2 0xc01b1011 in panic (fmt=0xc032a794 "from debugger")
at ../../kern/kern_shutdown.c:569
#3 0xc013c7dd in db_panic (addr=-1070605187, have_addr=0, count=-1,
modif=0xca4dbca0 "") at ../../ddb/db_command.c:433
#4 0xc013c77b in db_command (last_cmdp=0xc0371cf4, cmd_table=0xc0371b54,
aux_cmd_tablep=0xc03b6b60) at ../../ddb/db_command.c:333
#5 0xc013c842 in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc013eaaf in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc02fda0c in kdb_trap (type=3, code=0, regs=0xca4dbda0)
at ../../i386/i386/db_interface.c:164
#8 0xc030a418 in trap (frame={tf_fs = -901382120, tf_es = 16,
tf_ds = -1051394032, tf_edi = -1069770656, tf_esi = 256,
tf_ebp = -900874772, tf_isp = -900874804, tf_ebx = 2,
tf_edx = -1070199057, tf_ecx = 32, tf_eax = 18, tf_trapno = 3,
tf_err = 0, tf_eip = -1070605187, tf_cs = 8, tf_eflags = 86,
tf_esp = -1070199073, tf_ss = -1070347485}) at ../../i386/i386/trap.c:614
#9 0xc02fdc7d in Debugger (msg=0xc033cb23 "panic") at machine/cpufunc.h:60
#10 0xc01b1008 in panic (fmt=0xc033cf60 "runq_add: proc %p (%s) not SRUN")
at ../../kern/kern_shutdown.c:567
#11 0xc01b483c in runq_add (rq=0xc03c9860, p=0xca466420)
at ../../kern/kern_switch.c:142
#12 0xc01b47f5 in setrunqueue (p=0xca466420) at ../../kern/kern_switch.c:70
---Type return to continue, or q return to quit---
#13 0xc01a5750 in ithread_schedule (ithread=0xc1349100, do_switch=1)
at ../../kern/kern_intr.c:376
#14 0xc030ed8d in sched_ithd (cookie=0x5) at ../../i386/isa/ithread.c:99
#15 0x8 in ?? ()
#16 0xc01b3329 in issignal (p=0xca466420) at ../../kern/kern_sig.c:1410
#17 0xc01b116a in CURSIG (p=0xca466420) at ../../kern/kern_sig.c:190
#18 0xc030981e in userret (p=0xca466420, frame=0xca4dbfa8, oticks=2)
at ../../i386/i386/trap.c:179
#19 0xc030b3d3 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 2, tf_esi = 12, tf_ebp = -1077938440, tf_isp = -900874284,
tf_ebx = -2, tf_edx = 22195, tf_ecx = 17, tf_eax = 0, tf_trapno = 22,
tf_err = 2, tf_eip = 672387100, tf_cs = 31, tf_eflags = 646,
tf_esp = -1077938484, tf_ss = 47}) at ../../i386/i386/trap.c:1239
#20 0xc02fe393 in Xint0x80_syscall ()
#21 0x804d186 in ?? ()
#22 0x80495ac in ?? ()
#23 0x804915d in ?? ()
Script done on Sun Feb 25 22:28:05 2001
PGP signature
Scheduler panic
This is on a UP system.
Kris
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4767744
initial pcb at 3c9740
panicstr: from debugger
panic messages:
---
panic: runq_add: proc 0xca466420 (more) not SRUN
panic: from debugger
Uptime: 3h39m42s
dumping to dev #da/0x20001, offset 262144
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:476
476 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:476
#1 0xc01b0c3c in boot (howto=260) at ../../kern/kern_shutdown.c:319
#2 0xc01b1011 in panic (fmt=0xc032a794 "from debugger")
at ../../kern/kern_shutdown.c:569
#3 0xc013c7dd in db_panic (addr=-1070605187, have_addr=0, count=-1,
modif=0xca4dbca0 "") at ../../ddb/db_command.c:433
#4 0xc013c77b in db_command (last_cmdp=0xc0371cf4, cmd_table=0xc0371b54,
aux_cmd_tablep=0xc03b6b60) at ../../ddb/db_command.c:333
#5 0xc013c842 in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc013eaaf in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc02fda0c in kdb_trap (type=3, code=0, regs=0xca4dbda0)
at ../../i386/i386/db_interface.c:164
#8 0xc030a418 in trap (frame={tf_fs = -901382120, tf_es = 16,
tf_ds = -1051394032, tf_edi = -1069770656, tf_esi = 256,
tf_ebp = -900874772, tf_isp = -900874804, tf_ebx = 2,
tf_edx = -1070199057, tf_ecx = 32, tf_eax = 18, tf_trapno = 3,
tf_err = 0, tf_eip = -1070605187, tf_cs = 8, tf_eflags = 86,
tf_esp = -1070199073, tf_ss = -1070347485}) at ../../i386/i386/trap.c:614
#9 0xc02fdc7d in Debugger (msg=0xc033cb23 "panic") at machine/cpufunc.h:60
#10 0xc01b1008 in panic (fmt=0xc033cf60 "runq_add: proc %p (%s) not SRUN")
at ../../kern/kern_shutdown.c:567
#11 0xc01b483c in runq_add (rq=0xc03c9860, p=0xca466420)
at ../../kern/kern_switch.c:142
#12 0xc01b47f5 in setrunqueue (p=0xca466420) at ../../kern/kern_switch.c:70
---Type return to continue, or q return to quit---
#13 0xc01a5750 in ithread_schedule (ithread=0xc1349100, do_switch=1)
at ../../kern/kern_intr.c:376
#14 0xc030ed8d in sched_ithd (cookie=0x5) at ../../i386/isa/ithread.c:99
#15 0x8 in ?? ()
#16 0xc01b3329 in issignal (p=0xca466420) at ../../kern/kern_sig.c:1410
#17 0xc01b116a in CURSIG (p=0xca466420) at ../../kern/kern_sig.c:190
#18 0xc030981e in userret (p=0xca466420, frame=0xca4dbfa8, oticks=2)
at ../../i386/i386/trap.c:179
#19 0xc030b3d3 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 2, tf_esi = 12, tf_ebp = -1077938440, tf_isp = -900874284,
tf_ebx = -2, tf_edx = 22195, tf_ecx = 17, tf_eax = 0, tf_trapno = 22,
tf_err = 2, tf_eip = 672387100, tf_cs = 31, tf_eflags = 646,
tf_esp = -1077938484, tf_ss = 47}) at ../../i386/i386/trap.c:1239
#20 0xc02fe393 in Xint0x80_syscall ()
#21 0x804d186 in ?? ()
#22 0x80495ac in ?? ()
#23 0x804915d in ?? ()
Script done on Sun Feb 25 22:28:05 2001
PGP signature
