Re: gcc -O broken in CURRENT
Hi, This is a case of exception context register getting clobbered in shared library function call. GCC does not reload it when needed and this ultimately leads to semi-random word in program memory decremented by the __cp_pop_exception function. The bug is only triggered under very specific circumstances involving inline functions and nested degenerate exception handlers, that's why it existed unnoticed for quite some time. Do you have a patch for this ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Hi, Here are my test news. The -O bug doesn't happen with gcc295 from ports ! I tried all these FLAGS, but noone of them was creating the problems we see with -O : Optimization Options -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks -fdelayed-branch -felide-constructors -fexpensive-optimizations -ffast-math -ffloat-store -fforce-addr -fforce-mem -finline-functions -fkeep-inline-functions -fmemoize-lookups -fno-default-inline -fno-defer-pop -fno-function-cse -fno-inline -fno-peephole -fomit-frame-pointer -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fstrength-reduce -fthread-jumps -funroll-all-loops So what does -O exactly ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
STABLE is broken too, but in a different manner. I just added -O and
then this happened.
[algo] :testing inplace_merge #1() (weak) ... eh_test in free(): warning: junk
pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: modified (chunk-) pointer
# gdb eh_test eh_test.core
#0 0x806630b in void _STL::inplace_mergeSortClass * (__first=0xbfbff0ac,
__middle=0xbfbff23c, __last=0xbfbff3cc) at test_algo.cpp:58
58{
(gdb) bt
#0 0x806630b in void _STL::inplace_mergeSortClass * (__first=0xbfbff0ac,
__middle=0xbfbff23c, __last=0xbfbff3cc) at test_algo.cpp:58
#1 0x8066e8a in void WeakCheckSortBuffer, test_inplace_merge_1
(v=@0xbfbff83c, op=@0xbfbff434, max_iters=200) at test_algo.cpp:216
#2 0x804b41e in test_algo () at test_algo.cpp:248
#3 0x8049e37 in main (argc=3, argv=0xbfbffbe0) at main.cpp:275
#4 0x8049759 in _start ()
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded. All cpp* files are the same in the port and our system compilers. And ideas and pointers which subsystems I could test for this breakage ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? cd /usr/ports/devel/stlport make install cd work/STL*/test/eh add -O to gcc-freebsd.mk gmake -f gcc-freebsd.mk clean gmake -f gcc-freebsd.mk and see what happens ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Hi Kris, Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Easy to say, hard to do. STABLE is broken as current is, and it seems that 4.4 and 4.3 are also broken for the STLport test. This is a very difficult thing to do for someone that does not know gcc internals. Impossible for me. I don't have the resources (time) and knowledge (compiler coding) to do this. I can only state that: - plain gcc without patches works - gcc295 from ports works - gcc is STABLE and CURRENT is broken - It's not the dewarf unwinding. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: gcc -O broken in CURRENT
Hi all, Here are my test news. The -O bug doesn't happen with gcc295 from ports ! Previously I had stated before, the gcc295 from ports did not work too. but it seems that that was a user error :-) /usr/ports/devel/stlport (and the tests test/eh) can be succesfully be made. My staroffice build has survived the segfaulting part now in saxparser. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc -O broken in CURRENT
Hi all, Unfortunatly I have a example from the ports, needed by OpenOffice port (work in progress) cd /usr/ports/devel/stlport/ make install cd /usr/ports/devel/stlport/work/STLport-4.5.3/test/eh gmake -f gcc-freebsd.mak [vector] :testing n-size constructor (const) ... 95 try successful [vector] :testing pointer range constructor (const) ... Bus error - core dumped Then remove the three -O from gcc-freebsd.mak and run it again. You will see that all tests are successfully done. [...] [hash_multiset] :testing default constructor (const) ... 2 try successful [hash_multiset] :testing iterator range n-size constructor (const) ... 127 try successful [hash_multiset] :testing copy constructor (const) ... 54 try successful [hash_multiset] :testing assignment operator (weak) ... 53 try successful [...] [string] :testing copy constructor (const) ... 2 try successful [string] :testing assignment operator (weak) ... 1 try successful EH test : Done Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc_r patches and some questions
Hi Alfred,
if (errno != 0) {
if (dp == NULL)
The above patch should be committed.
Can you please commit it and I'll close PR misc/30631 after it has been MFC'd,
ok ?
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
FreeBSD unfinished NIS+ implementation in Linux ?
Hi all, While looking at nis-utils-1.4.1 from linux, I found that that whole package is based on Bill's work. Intersting that everything there is GNU labled. What happened to the BSD copyright ? Or has it been GPL'd from the beginning ? http://freshmeat.net/projects/nis-utils The author even forgot to remove one part of a manpage: nis-utils-1.4.1$ more man/nis_db.3 .Em The TI-RPCSRC 2.3 source code distribution. .Sh HISTORY This implementation of the .Nm nis_db library was written for and is scheduled to appear in a future release of FreeBSD 2.x as part of a complete, freely available NIS+ client and server package. This library was written entirely from scratch: no Sun code other than the publically available NIS+ header files was referenced. Strange thing. Bill, did you ever allowed them to make it GPL only ? Looking at the code it should be possible to import some things and make a NIS+ client available. But only if it's not GPL'd. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
Bills Work: http://people.freebsd.org/~wpaul/nis.tar.gz Suse Linux version: ftp://ftp.kernel.org/pub/linux/utils/net/NIS+/nis-utils-1.4.1.tar.bz2 An example from a file: File: db_add_entry.c Bills Copyright: /* * Copyright (c) 1996, 1997 * Bill Paul [EMAIL PROTECTED]. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: * This product includes software developed by Bill Paul. * 4. Neither the name of the author nor the names of any co-contributors *may be used to endorse or promote products derived from this software *without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY Bill Paul AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL Bill Paul OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ Suse's Copyright: /* Copyright (c) 1999 Thorsten Kukuk Author: Thorsten Kukuk [EMAIL PROTECTED] This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FW: Re: windbindd
Hi, Is there any way to impliment dl_open in our nsswitch for -current so that samba's winbindd can work on FreeBSD? no. There are plans to write a nssd proxy deamon for FreeBSD which does support loadable modules. I'll make nectar and my plans available in the next time. The goal is the have a working nssldap.so and a nsswinbind.so at the end. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: don't do that
Hi, After a migration of a complete / Filesystem with dump - restore. I made the mistake to already have a small new system on the new disk. So I decided to do a # cd / # restore urf root.dump I got at the end: /dev/ad0d: cannot create special file: File exists WARNING: Driver mistake: repeat make_dev(ad0s1) panic: don't do that Debugger(panic) Is this really a Driver mistake ? Or am I mistaken ? I guess we should do a # chflags nodump /dev during the install on CURRENT. Why has been /dev dumped anyway ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: don't do that
Hi, during the install on CURRENT. Why has been /dev dumped anyway ? I bet you have old /dev entries as a fallback left which got backed up. I guess no. This was a fresh CURRENT installation from November 2001. What do you see on a unmounted /dev? devfs cannot be unmounted as I know. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
netstat -f inet broken ?
Hi All, As we just have noted, there is no output anymore for netstat -f inet. Has the support been dropped ? Also there are only unix domain sockets in the normal netstat output. I cannot see any tpc4 connections anymore. I noted this in 4.5 PRERELEASE too. It used to work in 4.3 RELEASE and 4.4 RELEASE. So it got broken trough a MFC between 4.4 and 4.5. I think this is important for security reasons ! Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Solved: netstat -f inet broken ?
Works fine. Hi, I guess the world is not 100% up to date. I seems that I just got this after running a cvsup 2 hours later after the initial one. Shit happens. Thanks for the answer and sorry. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Can we use this ? Linux Interrupt Latency benchmark
Hi all, ftp://ftp.suse.com/pub/people/andrea/lil Maybe we can port this and use it to see where the latency actually happens ? See also this posting: http://groups.google.com/groups?q=latency+interrupt+linuxhl=enrnum=5selm=Pine.LNX.3.96.980827184103.250A-10%40dragon.bogus Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nsswitch with nss daemon and proxy
Hi Jacques, I've read that you've stopped working on our nsswitch implememtation. But now that CURRENT has been delayed for one year, it would be a really good time to finish your work. Not only because a working nss_ldap would be a great thing, also for a working samba winbind. This feature in Samba2.2.2 is working in Linux and Solaris only at the moment. :-(( If I can help you somewhere with your work, just tell me. Martin Martin Blapp, [EMAIL PROTECTED] | [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still panic() with userland binary on CURRENT
Hi DES, - realitexpire, td); + realitexpire, td-td_proc); Fixes the panic 100%. Thanks a lot ! Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Still panic() with userland binary on CURRENT
Hi DES, John, It does not lock the box completly, but it still panics. Sorry. DDB over serial connection: #./unilockd lock order reversal 1st 0xc04a8e80 sched lock @ /usr/src/sys/kern/kern_mutex.c:319 2nd 0xc049d8a0 sio @ /usr/src/sys/dev/sio/sio.c:2958 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x123423bd fault code = supervisor read, page not present instruction pointer = 0x8:0xc024d74a stack pointer = 0x10:0xcdc4dc70 frame pointer = 0x10:0xcdc4dc7c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 12 (swi6: tty:sio clock) kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x14e: movb0x45(%eax),%al db trace _mtx_lock_sleep(cf610f10,0,c03c7966,27b) at _mtx_lock_sleep+0x14e _mtx_lock_flags(cf610f10,0,c03c7966,27b,6) at _mtx_lock_flags+0x79 realitexpire(cf610d04) at realitexpire+0x24 softclock(0) at softclock+0x136 ithread_loop(c24ced00,cdc4dd48,c24ced00,c02470b8,0) at ithread_loop+0x12a fork_exit(c02470b8,c24ced00,cdc4dd48) at fork_exit+0x58 fork_t Martin Martin Blapp, [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
winbindd support for samba
Hi, Is someone working on winbindd support for Free/NetBSD ? #man winbindd NAME winbindd - Name Service Switch daemon for resolving names from NT servers winbindd is a daemon that provides a service for the Name Service Switch capability that is present in most modern C libraries. The Name Service Switch allows user and system information to be obtained from different databases ser- vices such as NIS or DNS. The exact behaviour can be con- figured throught the /etc/nsswitch.conf file. Users and groups are allocated as they are resolved to a range of user and group ids specified by the administrator of the Samba system. Btw, since we don't support winbindd, the samba-devel port should not install the manpage :-/ A winbind deamon is really needed if you have a big environment and you don't want to add all the time MACHINE$ entrys to /etc/passwd, on which samba depends if you have samba acting as a PDC. Winbindd(8) depends on nsswitch support. We have some nsswitch support, but NOT the sun API we could use to complile free available programms like samba. Linux has a SUN compatible NSS implementation. So either we fix or NSS implementation, or we modify with patches the winbindd to support FreeBSD too. Suggestions ? PS: IMHO this is a real issue and we should look how we can soon have a working winbindd on BSD. Martin Blapp, [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Multiple NFS server problems with Solaris 8 clients
Hi, One more problem is in nfsd, if I set it to use udp only it starts eating all cpu cycles it can get,but only the master process. Trussing the process shows no system calls whatsoever being performed. The last one is a know problem. There is a (unfinished) patch available to solve this problem. Thomas Moestl [EMAIL PROTECTED] is still working on some issues of the patch. Please contact him if you like to know more. Here is the URL for the patch: http://home.teleport.ch/freebsd/userland/nfsd-loop.diff Martin Martin Blapp, [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HELP needed for a outstanding commits
In late april I made some patches for tirpc, to fix outstanding issues with unix domain sockets. Since then, I'm trying to get these patches comitted. But all interested people have either no time or no interest. There exists also several PR's: bin/29171 [PATCH] keyserv and rpc.yppasswd bin/29172 [PATCH] Add more checks in rpc/svc_vc.c and bugfixes bin/29173 [PATCH] wrong flags for rpcgen(1) bin/29174 [PATCH] cleanup of the ti-rpc merger bin/29175 [PATCH] rpcgen(1) and inetdflag/pmflag support bin/29177 [PATCH] rpc client create functions with additional timeout Thomas Moestl is already working on bin/29175. This PR is also connected to PR bin/27816 bin/29177 [PATCH] rpc client create functions with additional timeout depends on how we treat now the new TIRPC2.8 license. The sun open source license wants that we add the whole license to the top of each changed file as I interpret it. (SunOS OSS license). I'm not sure if we can even integrate this patch ! Sun Industry Standards Source License 1.0 DEFINITIONS 1.1. Commercial Use means distribution or otherwise making the Original Code available to a third party. 1.2. Contributor Version means the combination of the Original Code, and the Modifications made by that particular Contributor. 1.3. Electronic Distribution Mechanism means a mechanism generally accepted in the software development community for the electronic transfer of data. 1.4. Executable means Original Code in any form other than Source Code. 1.5. Initial Developer means the individual or entity identified as the Initial Developer in the Source Code notice required by 2 (Exhibit A) 1.6. Larger Work means a work which combines Original Code or portions thereof with code not governed by the terms of this License. 1.7. License means this document. 1.8. Licensable means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently acquired, any and all of the rights conveyed herein. 1.9. Modifications means any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications. A Modification is: A. Any addition to or deletion from the contents of a file containing Original Code or previous Modifications. B. Any new file that contains any part of the Original Code or previous Modifications. . 1.10. Original Code means Source Code of computer software code which is described in the Source Code notice required by Exhibit A as Original Code. 1.11. Patent Claims means any patent claims, now owned or hereafter acquired, including without limitation, method, process, and apparatus claims, in any patent Licensable by grantor. 1.12. Source Code means the preferred form of the Original Code for making modifications to it, including all modules it contains, plus any associated interface definition files, or scripts used to control compilation and installation of an Executable. 1.13. Standards means the standard identified in Exhibit B or a subsequent version of such standard. 1.14. You or Your means an individual or a legal entity exercising rights under, and complying with all of the terms of, this License or a future version of this License issued under Section 6.1. For legal entities, You includes any entity which controls, is controlled by, or is under common control with You. For purposes of this definition, control means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity. 2.0 SOURCE CODE LICENSE 2.1 The Initial Developer Grant: The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims: a) under intellectual property rights (other than patent or trademark) Licensable by Initial Developer to use, reproduce, modify, display, perform, sub license and distribute the Original Code (or portions thereof )with or without Modifications, and/or as part of a Larger Work; and b) under Patents Claims infringed by the making, using or selling of Original Code, to make, have made, use, practice, sell, and offer for sale, and/or otherwise dispose of the Original Code (or portions thereof). c) the licenses granted in this Section 2.1(a ) and (b) are effective on the date Initial Developer first distributes Original Code under the terms of this License. d) Notwithstanding Section 2.1(b )above, no patent license is granted: 1) for code that You delete from the Original Code; 2) separate from the Original Code; or 3) for infringements caused by: i) the modification of the Original Code or ii) the combination of the Original Code with other software or devices, including but not limited to Modifications. 3.0 DISTRIBUTION OBLIGATIONS 3.1 Application of License. The Source Code version of Original
Re: Staroffice6.0 Linux beta with FreeBSD
Hi Marcel, What if you try it with linux_base-7? I've now more results. - The port works with old and new linux_base port, I it get started the right way. - Starting an install without -net does segfault suddenly. - Starting a user-install does segfault after registering the scripts. - Starting SO6.0 does loop indefinitly after starting it. You can find some linux_kdump output on the following location. Do you have a idea where it fails ? http://home.teleport.ch/freebsd/debug/ The port is still available on: http://home.teleport.ch/freebsd/ports/staroffice60.tgz Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Staroffice6.0 Linux beta with FreeBSD
While Openoffice for BSD is still milestones away from compiling, I tried to port the linux version of SO6.0 beta to FreeBSD. I got it extracted, and could run setup.bin, which fails miserably: 79358 setup.bin RET read 4096/0x1000 79358 setup.bin CALL linux_mmap(0xbfbfcfac) 79358 setup.bin RET linux_mmap 697401344/0x29918000 79358 setup.bin CALL mprotect(0x29932000,0x50ec,0) 79358 setup.bin RET mprotect 0 79358 setup.bin CALL linux_mmap(0xbfbfcfac) 79358 setup.bin RET linux_mmap 697507840/0x29932000 79358 setup.bin CALL linux_mmap(0xbfbfcfac) 79358 setup.bin RET linux_mmap 697528320/0x29937000 79358 setup.bin CALL close(0x6) 79358 setup.bin RET close 0 79358 setup.bin PSIG SIGSEGV SIG_DFL 79358 setup.bin NAMI setup.bin.core A full linux_kdump output is available. If someone knows more about this I'd be happy. BTW: This is CURRENT from today with a old linux base installed. Martin Blapp, [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS export to netgroup with duplicate hosts
Hi, Of course you are right. Netgroup support got in some area broken when I did the IPv6 merge of NetBSD code. It will be fixed soon, sorry ! Another issue with mountd is, that it allows still one set of flags for one mountpoint. This is done per radix entry in the kernel and tied to each file-system mount point. If we manage it, mountd should soon be able to allow different mount flags for each path you export in /etc/exports. 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: NFS export to netgroup with duplicate hosts
If we manage it, mountd should soon be able to allow different mount flags for each path you export in /etc/exports. I'm sorry. But now after some investigations and talks with Robert Watson it seems to be clear that this is not possible due the way nfs works. It would be easy to fix mountd, and to store somewhere the path where the export is tied to, but how should nfsd handle this ? He get's a request for a inode (the namei translation is done on the client side). The server has now to look which flag set belongs the inode. How can he see which set of flags belongs to that inode ? man share_nfs on solaris 7: Unlike previous implementations of share_nfs(1M), access checking for the window=, rw, ro, rw=, and ro= options is done per NFS request, instead of per mount request. In suns implementation of nfs is written (man share) If share commands are invoked multiple times on the same filesystem, the last share invocation supersedes the previous-the options set by the last share command replace the old options. For example, if read-write permission was given to usera on /somefs, then to give read-write permis- sion also to userb on /somefs: That means that it's not possible as I get it. I'll do further investigations to be sure how it works on Solaris exactly. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS export to netgroup with duplicate hosts
The reason is that the file handles passed to nfsd could then be trivially faked to gain rw access on a ro-exported subdirectory. For example, if you export /usr read-only and /usr/local read-write, you can then construct an NFS request using /usr/local's mount point but with a file handle that represents a file in /usr, and then be able to write to that file. This is because the file handle representing file X will be almost identical no matter which mount point X is accessed relative to. Yes I see. I'd also like to see what happens if you move some directory, or if you are doing hardlinks and also move them ... :-) Your explanation is logical to me. Maybe we should fix the exports(5) manpage. This is not a bug, it's a security restriction. It seems to me that we have a really good nfs implementation here on BSD, and we can do more finetuning than on Solaris itself. Also mountd and export seems to support more features than in Solaris, according to the manpage. Could this export restriction change in future with nfsv4, when nfs does get stateful (I've heard about that the stateless behaviour will go away with nfsdv4) ... ? I do not know much about the internals of nfsv4 ... Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel panic: resource_list_alloc: resource entry is busy
I see the same here with a GENERIC kernel. 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: [FIX] Re: CFS - Portmap
This should made cfs working again, please test the patch. http://home.teleport.ch/freebsd/mount_nfs.c.diff 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: [FIX] Re: CFS - Portmap
Hi, /etc/mount -o port=3049,intr localhost:/null /crypt What machine are you doing this on?? FreeBSD has no /etc/mount? Correct. I've used the sbin/mount of course, this is just a cut'n'paste of the documentation. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [FIX] (CFS/mount_nfs.c)
Hmm, can you try to stop/start cfsd again ? Is mountd also still running ? Martin PS: I've a little diff available to fix compile warnings and to use tirpc code instead of old rpc code in cfs: http://home.teleport.ch/freebsd/cfs.diff Can you try this out ? 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: [FIX] (CFS/mount_nfs.c)
BTW, my kernel is about week old while userland utilities very recent. Could it plays role? I.e. does new RPC require new kernel too? No. RPC-changes I've done are all in userland. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
tirpc and keyserv
Ok, I still really really disapointed about FreeBSD and the ways people are communicating together. But let's targeting keyserv ... For a local unix transport, (at the moment), you cannot just use svc_create(), that is neither implemented by sun not NetBSD. I fixed keyserv here and I'm testing it at the moment. I looked at suns code and have seen that the just copied code from svc_generic.c and used it for the local transport. Keyserv runs now here over local transport. 1000291unix /var/run/keyservsock keyservsuperuser That looks better ... I'll do further testing Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *** HEADSUP keyserv might be broken ***
keyserv _is_ broken. I'm sorry about this, I overlooked keyserv as I did my work and did just a hack so it compiled. There are a few things broken: - Register the keyserv programm and crypt program in rpcbind also for local unix transport. - Create and bind the unix socket I've a fix here, and I do testing at the moment. When everything works I'll paste it into the web. Btw: Rpcbind seems not to look at the v-flag in /etc/netconfig for rpcbind registrations. It works for portmap registrations. I'll look if this is still the same in newer tirpc1999. So you'll see these strange entries in rpcinfo: 100029 1unix /var/run/keyservsock keyservsuperuser 100029 2unix /var/run/keyservsock keyservsuperuser 6001000291unix /var/run/keyservsock superuser That's cause in /etc/rpc is no name defined for programm 600100029. Portmapper did hide this. 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: CFS - Portmap
If you have not recompiled cfs, does starting the rpcbind with -L fix this ? Old binarys resist to work without this option. from rpcbind man-page: Allow old-style local connections over the loopback interface. Without this flag, local connections are only allowed over a local socket, /var/run/rpcbind.sock 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
[FIX] Re: CFS - Portmap
It seems you have to run rpcbind with -i flag: -i ``insecure'' mode. Allows calls to SET and UNSET from an host. Normally rpcbind accepts these requests only from the loopback interface for security reasons. This change is necessary for programs that were compiled with earlier versions of the rpc library and do not make those requests using the loopback interface. # mount_nfs -o port=3049,intr localhost:/null /crypt root@fuchur:~# mount /dev/da0s2a on / (ufs, NFS exported, local, soft-updates) devfs on /dev (devfs, local) /dev/vinum/vol/vinum0 on /usr (ufs, NFS exported, local, soft-updates) /dev/da0s2e on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) linprocfs on /usr/compat/linux/proc (linprocfs, local) localhost:/null on /crypt (nfs) 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 On Thu, 22 Mar 2001, Martin Blapp wrote: If you have not recompiled cfs, does starting the rpcbind with -L fix this ? Old binarys resist to work without this option. from rpcbind man-page: Allow old-style local connections over the loopback interface. Without this flag, local connections are only allowed over a local socket, /var/run/rpcbind.sock 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: [FIX] Re: CFS - Portmap
Hmm ? # /usr/local/etc/rc.d/cfsd.sh stop # killall mountd # killall -SIGUSR1 nfsd # killall rpcbind # rpcinfo rpcinfo: can't contact rpcbind: RPC: Remote system error - Connection refused # rpcbind -i # mountd -2 # nfsd # /usr/local/etc/rc.d/cfsd.sh start # mount_nfs -o port=3049,intr,nfsv2 localhost:/null /crypt # mount [...] localhost:/null on /crypt (nfs) # umount -v /crypt # localhost:/null: unmount from /crypt 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 On Fri, 23 Mar 2001, Andrey A. Chernov wrote: On Thu, Mar 22, 2001 at 23:07:08 +0100, Martin Blapp wrote: It seems you have to run rpcbind with -i flag: -i not helps too. Diagnostic is the same. # mount_nfs -o port=3049,intr localhost:/null /crypt You miss "nfsv2" switch here. mountd is running with -2 option too. To make testing easy, put this into /etc/fstab: localhost:/null /crypt nfs rw,noauto,intr,port=3049,nfsv2 0 0 Then all you need is "mount /crypt" -- 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: [FIX] Re: CFS - Portmap
Without nfsd it doesn't work, right. Yes, this seems to be the problem. I'll go into source of cfs now and fix the problem. Or maybe a mount_nfs problem ? 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 On Fri, 23 Mar 2001, Andrey A. Chernov wrote: On Thu, Mar 22, 2001 at 23:32:53 +0100, Martin Blapp wrote: # nfsd ^ Not start nfsd - it is unneded for cfs, cfs handle all calls by itself. At least it works without any nfsd previously. -- 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: [FIX] Re: CFS - Portmap
Hmm, look at this: # mount /crypt mount_nfs: rpcbind on server: RPC: Program not registered rpcbind debug output: PMAP_GETPORT req for (13, 2, udp) from 127.0.0.1.3.18 :port = 0 nfs is prgramm 13 For some strange reason there is a request for nfs. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [FIX] Re: CFS - Portmap
Hi, I see, seems that (port==2049? nc : NULL) has changed in some way. I'll fix that. PS: let's change to private discussion and not cc current anymore. 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: [FIX] Re: CFS - Portmap
Ok,
here is what I found:
notes.ms, line 228
If your system does not support NFS mounts on ports other
than 2049, add -DCFS_PORT=2049; you will not be able to simultaneously
run the target system as an NFS server under this configuration.
cfs.h:#define CFS_PORT 2049
nfsproto.h:#define NFS_PORT 2049
nfsproto.x:const NFS_PORT = 2049
and then this code here:
if (!svc_reg(tp, NFS_PROGRAM, NFS_VERSION, nfs_program_2,
(port==2049? nc : NULL))) {
fprintf(stderr,"Can't register CFS NFS\n");
exit(1);
}
Cause the 5. argument (const char *nettype nc) is NULL in our case,
svc_reg does not register cfs within rpcbind.
If you compile with -DCFS_PORT=2049, cfs works as normal.
I'm only thinking what is the right thing to do ...
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
On Thu, 22 Mar 2001, Alfred Perlstein wrote:
* Martin Blapp [EMAIL PROTECTED] [010322 15:00] wrote:
Hi,
I see, seems that (port==2049? nc : NULL) has changed in some way.
I'll fix that.
PS: let's change to private discussion and not cc current anymore.
Please don't, I'd like to understand what's going on here.
There's also a chance someone will jump in with the answer you're
looking for.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [FIX] Re: CFS - Portmap
Breaking nfs from working on user defined ports is a step backwards and should be fixed. Lots of people run nfsd and cfsd at the same time. No, you understand me wrong, the way this is done is bogus. If you set -DCFS_PORT=3049 like it is done at the moment and use nc instead of NULL it works. To have a NULL nc entry is not correct in tirpc. /etc/mount -o port=3049,intr localhost:/null /crypt Works here if I remove this check. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [FIX] Re: CFS - Portmap
I'm fixing now the code ... We have to use now Solaris code part and add #if defined(__FreeBSD__) || defined (__SOLARIS2X__) ifdef's and also fill out this: /* Assign the local bind address and type of service */ tp-xp_ltaddr = tres-addr; tp-xp_type = tinfo.servtype; tp-xp_rtaddr.len = 0; tp-xp_rtaddr.maxlen = tres-addr.maxlen; tp-xp_netid = strdup(nc-nc_netid); tp-xp_tp = strdup(nc-nc_device); Then we can use it again. Fix is on the way, just have pation. 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: [FIX] Re: CFS - Portmap
I'll go to bed now. It's not cfsd which does this. My update of mount_nfs (and syncing source with NetBSD) broke this. I'll change mount_nfs so this works again. There is no need for mount_nfs to register nfs within rpcbind if port=0. Sorry that this last so long to detect. 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
*HEADSUP* /etc/netconfig
Afer installworld in CURRENT, you'll have to run mergemaster ( or install /etc/netconfig ) manually if you run any rpc-services. Else you'll see strange errors like this: - can't get net id for host/nfs: servname not supported for ai_socktype - Protocol not supported - rpcbind on server: RPC: Unknown host This should also go into the UPDATING section. 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
MD5 mergemaster
Hi Doug and all others.
here is a first version of the MD5 mergemaster. It works like this:
No checksum in existing /etc file
-
- If a installed version of a /etc file is the same as the temproot
version, we add a md5 checksum to the cvs-header of the file and
install it again.
- If it differs from from the temproot version, we show as usual
the merge/install page, and when we do the install, we add the
md5 checksum.
Checksum already in /etc file:
--
- If the checksum of the /etc file is the as the fresh file, we do
nothing and skip.
- If the checksum of header of the /etc file is the same as the generated
from /etc, we let it install the new version, if there is any, else we
skip.
- If these checks are unsucessfull, we just hand it to the diff routine
and let diplay the changes you made in the /etc files.
I think there may be some things to change, but it works for me at the
moment. Fixes are welcome. Maybe it's also a good thing to add a flag
for these checks, so you can turn off and on the new behaviour.
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
--- /usr/sbin/mergemaster Fri Mar 16 08:01:20 2001
+++ mergemaster Sun Mar 18 20:25:11 2001
@@ -8,7 +8,7 @@
# Copyright 1998-2001 Douglas Barton
# [EMAIL PROTECTED]
-# $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.17 2001/03/05 10:13:21 dougb
Exp $
+# $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.6 2001/03/05 20:33:28
+dougb Exp $
PATH=/bin:/usr/bin:/usr/sbin
@@ -112,7 +112,9 @@
echo ''
echo " *** Displaying differences between ${COMPFILE} and installed
version:"
echo ''
- diff "${DIFF_FLAG}" "${DESTDIR}${COMPFILE#.}" "${COMPFILE}"
+ /usr/bin/sed -E -e 's%MD5=*.{32} %%' "${DESTDIR}${COMPFILE#.}"
+"${COMPFILE}.orig"
+ diff "${DIFF_FLAG}" "${COMPFILE}.orig" ${COMPFILE}
+ rm "${COMPFILE}.orig"
) | ${PAGER}
echo ''
fi
@@ -490,11 +492,6 @@
;;
esac
- # Avoid trying to update MAKEDEV if /dev is on a devfs
- if /sbin/sysctl vfs.devfs.generation /dev/null 21 ; then
-rm ${TEMPROOT}/dev/MAKEDEV ${TEMPROOT}/dev/MAKEDEV.local
- fi
-
;; # End of the "RERUN" test
esac
@@ -643,7 +640,12 @@
case "${DONT_INSTALL}" in
'')
+ /bin/cp ${1} ${1}.orig
+ GENMD5=`/usr/bin/grep -v "[$]${CVS_ID_TAG}:" "${1}" | /sbin/md5`
+ SEDSTRING="'s%Exp \\\$\$%Exp MD5=${GENMD5} \\\$%'"
+ eval "/usr/bin/sed -E -e ${SEDSTRING} \"${1}.orig\" \"${1}\""
install -m "${FILE_MODE}" "${1}" "${DESTDIR}${INSTALL_DIR}"
+ rm ${1}.orig
;;
*)
unset DONT_INSTALL
@@ -676,6 +678,69 @@
#
for COMPFILE in `find . -type f -size +0`; do
+ # get the MD5 checksum of the CVS header of ${DESTDIR}${COMPFILE#.}
+ MD5ID_OLD=`/usr/bin/grep "[$]${CVS_ID_TAG}:" ${DESTDIR}${COMPFILE#.} 21 |
+/usr/bin/sed -E -e 's%^.*MD5=(.{32}).*$%\1%' 21`
+
+ # Generate the MD5 checksum of the installed file
+ GENMD5_OLD=`/usr/bin/grep -v "[$]${CVS_ID_TAG}:" ${DESTDIR}${COMPFILE#.} |
+/sbin/md5`
+
+ # Generate the MD5 checksum of ${COMPFILE}
+ GENMD5_NEW=`/usr/bin/grep -v "[$]${CVS_ID_TAG}:" ${COMPFILE} | /sbin/md5`
+
+ # Get the CVS_ID lines without MD5 checksum
+ CVSID_OLD=`/usr/bin/grep "[$]${CVS_ID_TAG}:" ${DESTDIR}${COMPFILE#.} | /usr/bin/sed
+-E -e 's%MD5=.{32}%%' 2/dev/null`
+ CVSID_NEW=`/usr/bin/grep "[$]${CVS_ID_TAG}:" ${COMPFILE} 2/dev/null | /usr/bin/sed
+-E -e 's%MD5=.{32}%%' 2/dev/null`
+
+ #
+ # Check if no MD5 checksum exits in the installed version.
+ #
+ case "${MD5ID_OLD}" in
+ "${CVSID_NEW}")
+ #
+ # No MD5 checksum available, if the files are exactly the
+ # same we can add a MD5 checksum to the cvs header.
+ #
+ case "${GENMD5_OLD}" in
+ "${GENMD5_NEW}")
+ #
+ # New File is the same as the installed version
+ # so we can savly install the new version with
+ # generated md5 checksum.
+ #
+ mm_install "${COMPFILE}"
+ continue
+ ;;
+ esac
+ ;;
+ *)
+ #
+ # MD5 checksum available
+ #
+ case "${MD5ID_OLD}" in
+ "${GENMD5_NEW}")
+ #
+ #
Re: MD5 mergemaster
Doug, Database access in a shell script ? Tell me how to do this and I'll do. Else I'll rewrite mergemaster in perl. Yes - I think this is a good idea, shell-scripts just suck ! And mergemaster is badly formatted too, it's not easy to programm like this (yes I know the formatting is needed to properly have the echo "" s, but that sucks a lot. I'll not do some database access in a shell script. 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: Proposal to mergemaster
Hmm, just some thoughts here: I modified mergemaster so he add's to every file he touches or installs this md5 checksum. When mergemaster reads a file and compares it, it extracts the md5 checksum form the file (if it exists) and looks if the file has been changed or not. If a new file get's installed, the md5 checksum of that file is written. For the first time you update you have the same way to go as usual. but the second time, you will be only asked for the files which have been modified. Even if 90% of the config files have new $ID's and are a lot different. If it is possible to add these checksums also in sysinstall when extracting the first time you install, nothing has to be done with commit scripts and also the first time you run mergemaster, you can run it a lot more faster than now. 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 On Tue, 13 Mar 2001, Jordan Hubbard wrote: Hmmm, this is nice! I've wanted this option for a long time. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to mergemaster
Hi Jordan, If it is possible to add these checksums also in sysinstall when extracting the first time you install, nothing has to be done with commit scripts and also the first time you run mergemaster, you can run it a lot more faster than now. Can you be more specific? Some diffs would certainly be easier to grasp the meaning of. :) Yes, I mean when we extract and install all /etc files, is it possible to add then then md5 checksum to all installed config files into the cvs header ? (With grep -v "$FreeBSD:" of course). 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
Proposal to mergemaster
Hi, After 100erts of mergemaster sessions, I'm looking for a way to improve mergemaster. 1st thing, mergemaster displays per default all in changed files. That's ok for the first time, but if you maintain many hosts, this is annoying a lot. There should be an options to display all changed files anyway, so you can watch what has changed. (but off by default) So I have ideas to improve merge-master: 1. Add md5 checksum to the the file-header: --- Add an md5 checksum in the header of the File, maybe in $FreeBSD$ when the file get's comitted. (The $FreeBSD$ line should be sed'd/grepp'd out to md5 the raw file without checksum.) grep -v "$FreeBSD:" defaults/rc.conf | md5 Example: # $FreeBSD: src/etc/defaults/rc.conf,v 1.53.2.15 2001/01/28 20:57:35 jdp Exp md5="1fff7b9d6f6daa0ea9635873bfd0b7cd" $ Then mergemaster can do a md5 over the config file and look if the file has changed. If so, you get asked to merge or install a newer version. If the md5 checksum is the same, the config file get's updated without asking the user. 2. Have a special database with md5 checksums - The advantage here is that we can use this for binarys also, and this allows us to have binary updates for, let's say, security fixes. For old unsupported releases that's a very good thing. The database stores all md5 checksums for every version of a configfile we had (for this branch so it dosn't get to big ?) The database could also be very useful for later usage in the ports- tree (handle make update) Other ideas are welcome 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: Proposal to mergemaster
Hi, If you didn't change a file and it was at 1.45 then if the new one is at 1.55 you should just install it. Since you didn't touch it at 1.45 you will probably not want to touch it at 1.55 either. yes, of course. but I don't see your point. Am I missing something ? How can you see it hasn't been changed ? Version numbers do not tell anything, an md5 checksum will prove 100% that a files has been modified or not. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux_connect patch
Hi Jonathan,
I tested yout patch with CURRENT and STABLE, and it does
fix the Staroffice Network-Problem too.
I tested:
Linux SO5.2
Linux Netscape 4.7
Linux linux-jdk1.3.0, green threads (digichat)
and everythings works. So please commit this,
and it should also go into STABLE before 4.3
is out. This fix is really necessary.
Martin
+ /*
+ * Linux doesn't return EISCONN the first time it occurs,
+ * when on a non-blocking socket. Instead it returns the
+ * error getsockopt(SOL_SOCKET, SO_ERROR) would return on BSD.
+ */
+ error = holdsock(p-p_fd, linux_args.s, fp);
+ if (error)
+ return (error);
+ error = EISCONN;
+ if (fp-f_flag FNONBLOCK) {
+ so = (struct socket *)fp-f_data;
+ if ((u_int)so-so_emuldata != 0)
+ error = so-so_error;
+ so-so_emuldata = (void *)1;
}
-
+ fdrop(fp, p);
return (error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[PATCH] for linux_connect (ugly)
Hi, Thomas Moestl and I tried to fix linux_connect. Most of this patch is from Thomas Moestl. I did only a little part of it and testing. Staroffice5.2 has been broken about one year now, and it needs a fix with the same behaviour to work correctly with FreeBSD. This patch should be rewritten so it can be comitted to CURRENT and (IMPORTANT) to STABLE before 4.3 is out. --- src/sys/sys/socket.h.orig Wed Feb 28 01:02:42 2001 +++ src/sys/sys/socket.hWed Feb 28 01:02:10 2001 @@ -79,6 +79,7 @@ #defineSO_REUSEPORT0x0200 /* allow local address port reuse */ #defineSO_TIMESTAMP0x0400 /* timestamp received dgram traffic */ #defineSO_ACCEPTFILTER 0x1000 /* there is an accept filter */ +#define SO_KNBCONN 0x2000 /* kluge bit for linuxulator connect */ /* * Additional options, not kept in so_options. --- src/sys/compat/linux/linux_socket.c.origWed Feb 28 00:58:00 2001 +++ src/sys/compat/linux/linux_socket.c Wed Feb 28 01:00:51 2001 @@ -41,6 +41,8 @@ #include sys/sysproto.h #include sys/fcntl.h #include sys/socket.h +#include sys/socketvar.h +#include sys/file.h #include sys/uio.h #include netinet/in.h @@ -424,8 +426,9 @@ int *avalsize; } */ bsd_getsockopt_args; void *status, *statusl; - int stat, statl = sizeof stat; + int stat, iconn, statl = sizeof stat; caddr_t sg; + struct file *fp; /* Check for non-blocking */ bsd_fcntl_args.fd = linux_args.s; @@ -453,9 +456,27 @@ if ((error = copyin(status, stat, sizeof stat))) return (error); + /* +* Ugly kluge: some applications depend on 0 being +* returned only the first time. Therefore, we set +* the (otherwise invisible) SO_KNBCONN flag. +* If it is set, return EISCONN. +*/ + error = holdsock(p-p_fd, linux_args.s, fp); + if (error) + return (error); + iconn = ((struct socket *)fp-f_data)-so_options + SO_KNBCONN; + ((struct socket *)fp-f_data)-so_options |= SO_KNBCONN; + fdrop(fp, p); + + if (iconn) + return (EISCONN); + p-p_retval[0] = stat; return (0); - } + } else + return (EISCONN); } return (error); 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: some proposals about nfsd(8)
What argument are you passing to rpcinfo?
That info was from tirpc (rpcbind) and a modified nfsd(8) which
was originally ported from NetBSD and adapted to our nfsd(8):
http://home.teleport.ch/freebsd/newnfsd.c
It seems our way doing the registration was wrong (but only for
doing bindhost stuff). If you have specified binding to two
hosts, like 'nfsd -h ip1 -h ip2', pmap_set was called twice or
more times in the for loop:
for (i = 0; udpflag i bindhostc; i++) {
}
And that's at least for rpcbind wrong, cause rpcbind registers
it with the ai_udp-ai_addr. It may work in portmapper cause
there's a much more simpler registration there.
As you said, portmapper does only register ports, not ports
binded to a interface or an ip.
I've changed the way nfsd(8) does the registration. I get now
the same results in rpcinfox. If I bind to one or more IP's,
the portmapper registration is the same now:
#nfsd -u -t or
#nfsd -u -t -h localhost
#nfsd -u -t -h host1 -h host2
132udp 0.0.0.0.8.1nfssuperuser
133udp 0.0.0.0.8.1nfssuperuser
132udp6 ::.8.1 nfssuperuser
133udp6 ::.8.1 nfssuperuser
132tcp 0.0.0.0.8.1nfssuperuser
133tcp 0.0.0.0.8.1nfssuperuser
132tcp6 ::.8.1 nfssuperuser
133tcp6 ::.8.1 nfssuperuser
I also added a new option to nfsd, to unregister within rpcbind:
nfsd -d (removes the registration entrys in rpcbind)
Martin
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
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
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: 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
TI-RPC and NFS6 status (100% done)
Hi,
I have finished now my work here with TI-RPC, and I'm only doing
bug-fixing now before this gets comitted.
I'd like that many people test these changes and send me bugreports
back. This is a port from NetBSD, and as in NetBSD, it uses Unix Domain
Sockets instead of TLI/XLI stuff. I'v taken the credential checking stuff
from our previous RPC implementation, thanks to Bill Paul for the work he
has done there.
There are still some little things to do in future:
- Fix manpages
- Fix 'bind to ip' for nfsd which is broken at the moment
- Upgrade locking stuff in rpc.library to latest version (ti-rpc2.3)
Here are the patches:
http://home.teleport.ch/freebsd/rpc.diff_02202001.tgz
http://home.teleport.ch/freebsd/before-patch.sh
To patch the CURRENT source-tree and to install these changes, do the
following steps:
1. cd /usr/src
2. run ./before-patch.sh
3. patch -I -E -p rpc.diff_02202001
4. make world
5. Run mergemaster
With these patches applied, all rpc dependent programms in FreeBSD still
work and compile, nfsd(8) and mountd(8) and the mount utilities
(mount_nfs, umount, prc.umntall) have been patched to support IPv6, and
I'm using here NFS over UDP6 on localhost sucessfully.
This is an output of rpcinfo(8), which also has been updated:
# rpcinfo
program version netid addressserviceowner
104tcp 0.0.0.0.0.111 rpcbindsuperuser
103tcp 0.0.0.0.0.111 rpcbindsuperuser
102tcp 0.0.0.0.0.111 rpcbindsuperuser
104udp 0.0.0.0.0.111 rpcbindsuperuser
103udp 0.0.0.0.0.111 rpcbindsuperuser
102udp 0.0.0.0.0.111 rpcbindsuperuser
104tcp6 ::.0.111 rpcbindsuperuser
103tcp6 ::.0.111 rpcbindsuperuser
104udp6 ::.0.111 rpcbindsuperuser
103udp6 ::.0.111 rpcbindsuperuser
104unix /var/run/rpcbind.sock rpcbindsuperuser
103unix /var/run/rpcbind.sock rpcbindsuperuser
102unix /var/run/rpcbind.sock rpcbindsuperuser
151udp 0.0.0.0.3.252 mountd superuser
153udp 0.0.0.0.3.252 mountd superuser
151tcp 0.0.0.0.3.254 mountd superuser
153tcp 0.0.0.0.3.254 mountd superuser
151udp6 ::.3.251 mountd superuser
153udp6 ::.3.251 mountd superuser
151tcp6 ::.3.253 mountd superuser
153tcp6 ::.3.253 mountd superuser
132udp 0.0.0.0.8.1nfssuperuser
133udp 0.0.0.0.8.1nfssuperuser
132udp6 ::.8.1 nfssuperuser
133udp6 ::.8.1 nfssuperuser
And I can do:
# mount -v ::1:/usr/ports/ /mnt
::1:/usr/ports on /mnt (nfs)
# ls -l /mnt
total 1353
-rw-r--r--1 root wheel 19 Jul 14 1997 .cvsignore
drwxr-xr-x2 root wheel 512 Dec 25 1999 CVS
[...]
# umount -v ::1:/usr/ports/
::1:/usr/ports: unmount from /mnt
Now to the other changes which are included in this patch:
- Portmapper(8) has been replaced by the son of portmap, rpcbind.
- There is also a fix included for ypbind, to not to sent 1ends of
requests out, if the yp-server is away for a little time.
- Umount(8) is also fixed to unmount pathnames longer than 80 chars, which
are currently truncated by the Kernel statfs structure.
- In rc.network, all rpc dependent programms and servers are only started
if ${portmap_enable} is set to "YES". In defaults/rc.conf there are some
comments about this. This should prevent some hangs for rpc dependent
programms (rpc.umntall, nfsd, ypbind etc.)
- Because I was to lazy to fix our rpc.lockd(8), I've included the working
NetBSD rpc.lockd(8) implementation, wich uses TI-RPC and works fine for
server side locking, client side locking is not implemented yet.
Im doing some patch splits now, so all necessary parts will hopefully
be commited by Alfred Perlstein in the next few days.
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: TI-RPC and NFS6 status (100% done)
Hi, I've found some inconsistency in my CVS tree, and sbin/mountd/mountd.c was not the version it should have been. That's fixed now and world just finished on my box sucessfully. Thanks to Ruslan (new man-pages are included in second patch today). Location is still the same, I've just updated the patch to include the changes. http://home.teleport.ch/freebsd/rpc.diff_02202001-1.tgz Thanks to everybody who sent me email about bugs or just comments. 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
New GCC changes broken
Do people test their changes ? warning: passing arg 1 of `unshare_all_rtl' from incompatible pointer type ... /usr/current/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc.295/toplev .c:3828: too few arguments to function `unshare_all_rtl' *** Error code 1 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: New GCC changes broken
On another box CURRENT, updated this morning: cc -I/usr/src/lib/csu/i386-elf/../common -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/csu/i386-elf/crti.S -o crti.o cc: Internal compiler error: program as got fatal signal 11 as(1) does crash, rebuilding as does not help, neither does rebuilding gcc, I cannot compile and .S files. 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 On Sat, 17 Feb 2001, Martin Blapp wrote: Do people test their changes ? warning: passing arg 1 of `unshare_all_rtl' from incompatible pointer type ... /usr/current/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc.295/toplev .c:3828: too few arguments to function `unshare_all_rtl' *** Error code 1 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: New GCC changes broken
Did that, replaced /usr/libexec/elf/as with new one, now I have: cc -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DYP -DHESIOD -I/usr/src/lib/libc/i386 -c read.S -o read.o ld: unrecognized option `-x' Sigh ... 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
(solved) New GCC changes broken
Ok, I replaced all bintools in /usr/bin/* and /usr/libexec/elf/* . Everything works now and I successfully built world just now. That was a scary day to compile. 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 On Sat, 17 Feb 2001, Martin Blapp wrote: Did that, replaced /usr/libexec/elf/as with new one, now I have: cc -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DYP -DHESIOD -I/usr/src/lib/libc/i386 -c read.S -o read.o ld: unrecognized option `-x' Sigh ... 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: New GCC changes broken
Everything works now, thanks ! 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 On Sat, 17 Feb 2001, David O'Brien wrote: On Sat, Feb 17, 2001 at 01:54:29PM +0100, Martin Blapp wrote: Do people test their changes ? warning: passing arg 1 of `unshare_all_rtl' from incompatible pointer type ... /usr/current/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc.295/toplev .c:3828: too few arguments to function `unshare_all_rtl' *** Error code 1 Sounds like you CVSup'ed in between my import and fixing of conflicts. Please let me know if you still have problems. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fix for mountpath lenght
In mount.h, we have a #define MNAMELEN80
and in struct statfs {} we have:
charf_mntonname[MNAMELEN]; /* directory on which mounted */
but the kernel does no check to see if the mountpath is longer
than MNAMELEN, it just accepts it ? It's impossible to umount(8)
it, because umount(8) does not like to unmount some device which
does not belong to the mountpoint.
--- vfs_syscalls.c Sun Nov 26 03:30:05 2000
+++ vfs_syscalls.c.new Thu Feb 15 18:22:13 2001
@@ -140,6 +140,8 @@
/*
* Get vnode to be covered
*/
+ if (strlen(SCARG(uap, path)) MNAMELEN)
+ return (ENAMETOOLONG);
NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE,
SCARG(uap, path), p);
if ((error = namei(nd)) != 0)
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
TI-RPC status (99% done)
Hi all, I have reworked my patches and I run now successfully CURRENT with them, make buildworld has been sucessfull and everything seems to work so far. http://www.attic.ch/patches/rpc.diff_02082001-2.sh.tgz Can't we commit this to CURRENT now ? I'd like to see a history of my changes, I don't have the patch in cvs here, and I'd like that others see the changes too and can tell me if they are correct. These are the changes I have done on this release. # rpc.diff_02082001-2: # Added IPPROT_ST to rpcinfo and rpcbind to correct # output of 'rpcinfo -p'. All Unix socket connections # are correctly displayed as 'local' instead of garbage. # # Corrected rpcinfo.8 to be correctly displayed. I had # to convert all .Nm "" to .Nm # # Fixed some .rej, some man-pages have been updated. # # Removed again some _THREAD_SAFE definitions to make # it fit to the new CURRENT libc-format. More on this # will follow this week. Just go into you CURRENT Source tree and run the patch.sh, then make world and run mergemaster after (to copy all needed files like netconfig and the patches defaults/rc.conf Thank you for your time you spend on the patch. 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
/usr/src/UPDATING
Hi Warner, Can you add a remark about the devfs and vinum conflict to UPDATING ? I had serious problems today, because I have been bitten by this conflict. Devfs is now in GENERIC-KERNEL in CURRENT, and if you upgrade and have vinum set up on on /usr, you cannot mount it - no way. mkdir: /dev/vinum: Operation not supported mkdir: /dev/vinum: Operation not supported mkdir: /dev/vinum: Operation not supported mkdir: /dev/vinum: Operation not supported Can't create /dev/vinum/Control: No such file or directory Can't create /dev/vinum/control: No such file or directory Can't create /dev/vinum/controld: No such file or directory Can't get vinum config: Bad file descriptor Can't open /dev/vinum/Control: Bad file descriptor It is not possible to unmount devfs, so only way is to boot an old kernel (if it works) or boot a cd-rom. This should be definitly in UPDATING. You have to compile a Kernel without devfs. Possible Text: Remove "option devfs" from your KERNEL-CONFIG if you are using vinum and you upgrade from STABLE. Else you cannot mount your vinum-volumes. 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: (KAME-snap 3974) Re: TI-RPC, IPv6 and NFS (was: Re: strongrecommendationre: NFS)
As I already wrote in a prior statement, Alfred Perlstein and I ported TI_RPC to FreeBSD. It compiles with recent CURRENT. http://www.attic.ch/patches/rpc.diff_01152001-2.sh.tgz All you have to do is to start rpc.diff_01152001-2.sh in the source tree and make a buildworld and then run mergemaster (installing etc/defaults/rc.conf and etc/netconfig) Then the system is ready. 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: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Hi, So, I have merged in the newest libc changes and fixed some buildworld issues. It still needs some _THREAD_SAFE fixes I guess, cause we build now thread-safe libc per default. But we can do this later ... Go into your CURRENT source tree and execute the shell archive, it will create the necessary directories and remove some files to prevent appling files two times. You find the TI-RPC patch on: http:/www.attic.ch/patches/rpc.diff_04022001.sh.tgz 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: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Argl, the correct URL is of course: http://www.attic.ch:80/patches/rpc.diff_04022001.sh.tgz Cheers: 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 On Mon, 5 Feb 2001, Martin Blapp wrote: Hi, So, I have merged in the newest libc changes and fixed some buildworld issues. It still needs some _THREAD_SAFE fixes I guess, cause we build now thread-safe libc per default. But we can do this later ... Go into your CURRENT source tree and execute the shell archive, it will create the necessary directories and remove some files to prevent appling files two times. You find the TI-RPC patch on: http:/www.attic.ch/patches/rpc.diff_04022001.sh.tgz 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
TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Hi, Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find the latest snapshot here: http://www.attic.ch/rpc.diff_01114001.tgz Patches and bugfixes are welcome. 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: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Hi, I'll place a new version tomorrow on the server. be patient untill then. 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 On Fri, 26 Jan 2001, Jun Kuriyama wrote: At 25 Jan 2001 19:08:14 GMT, Martin Blapp wrote: http://www.attic.ch/rpc.diff_01114001.tgz I cannot fetch it. Gone into attic? :-) -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday
Hi Matt, I really like to see your fix committed to STABLE. It fixes also the bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). Thank you for your work ! 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: move portmap(8) from /usr/sbin to /sbin
portmap(8) and therefore mountd(8) should be started before the nfs filesystems get mounted. But because portmap(8) is in /usr/sbin , users with a nfs mounted /usr filesystem or with diskless filesystems will have big problems. I mean, that if I do the change of startup-order, diskless installations will be broken. This will fix loopback and local mounts in fstab. Untill now this has not been possible because of the above reasons. Btw: Linux also has portmap(8) installed in /sbin. You only need portmap and mountd to _export_ nfs, not to mount them. For a normal installation this is ok, but as I said, diskless installs ... Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
Hi, should not have to run either, *even* for diskless boot. What's all this about loopback mounts in fstab about? What does that have to do with diskless startup? Ok. I just rethought everything. It seems that a move is unnecessary because: - Sharity light and cfs are started from /usr/loca/etc/rc.d - diskless stations do not have anything to export So are there any problems with the order change in /etc/rc.network (moving portmap and mountd to network pass_1) you can imagine ? Thanks for the fast response and your ideas. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
I've got a loopback mount in /var/db/mounttab that looks like this: 946789037 localhost /null which is there because I run cfs (a crypto file system; see /usr/ports/security/cfs). Part of the cfs startup script does this: /usr/local/sbin/cfsd mount -o port=3049,intr localhost:/null /crypt The problem is that when you boot, the invocation of 'rpc.umntall -k' hangs for a while trying to contact the mountd or portmapper on localhost. If it was smart enough to recognize an ICMP port unreachable error and move on, we wouldn't have this problem. It's not that I think moving mountd and portmap is necessarily a good idea; this is just one scenario which perhaps has prompted this line of That's because rpc.umntall has been called the wrong time. I have another patch which does fix this behaviour. Thanks anyway. BTW: you cannot have this line in /etc/fstab, right ? If you put localhost:/null /crypt in fstab, you will get a hang at boottime. Are there other cases for which we will have problems ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
proposed /etc/rc.network change ?
Hi all, I propose to change rc.network in the way that portmapper and the nfs services are started _before_ any nfs filesystems get mounted. This will fix loopback and local mounts in fstab. But cause portmap is located in /usr/sbin, we have to move it into /sbin, else some nfs mounted /usr users will complain ! And here is the patch: http://www.attic.ch/patches/mntrpc.patch. Just look at the part in the middle '/etc/rc.network'. Thanks for discussions und suggestions ! 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: ATA driver problem?? (lost disk contact)
hi, I've bought two new 16GB ATA disks and am not able to boot anymore since wd0 has been retired: Fresh current from today: [...] ad0: ad_timeout: lost disk contact ata0: resetting devices and after it hangs forever. I tried IDE_DELAY=1 and 15000 but it did not change anything. Break into DDB is not possible. This happens with/without ATA DMA support in the kernel. fuchur# pciconf -l chip0@pci0:0:0: class=0x06 card=0x chip=0x70061022 rev=0x23 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x chip=0x70071022 rev=0x01 hdr=0x01 isab0@pci0:7:0: class=0x060100 card=0x chip=0x74081022 rev=0x01 hdr=0x00 ide_pci0@pci0:7:1: class=0x01018a card=0x chip=0x74091022 rev=0x03 hdr=0x00 chip1@pci0:7:3: class=0x068000 card=0x chip=0x740b1022 rev=0x03 hdr=0x00 none0@pci0:7:4: class=0x0c0310 card=0x chip=0x740c1022 rev=0x06 hdr=0x00 de0@pci0:10:0: class=0x02 card=0x chip=0x00091011 rev=0x20 hdr=0x00 none1@pci0:11:0:class=0x01 card=0x10001000 chip=0x000f1000 rev=0x26 hdr=0x00 vga-pci0@pci1:5:0: class=0x03 card=0x2179102b chip=0x0525102b rev=0x04 hdr=0x00 and the output from the old wd driver: wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): IBM-DJNA-351520 wd0: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): TOSHIBA CD-ROM XM-6202B/1110, removable, accel, ovlap, dma, iordis Device wcd0a: name slot allocation failed (Errno=17) Device wcd0c: name slot allocation failed (Errno=17) wcd0: drive speed 5512KB/sec, 256KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA wcd0: Audio: play, 255 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (wd2): IBM-DJNA-351520 wd2: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S wdc1: unit 1 (atapi): IOMEGA ZIP 100 ATAPI/23.D, removable, intr, iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set Martin PS: I can give you access to the machine if you like. 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: ATA driver problem?? (lost disk contact)
Sorry, I found a rather easy workaround. Disable DMA for the disks in the BIOS ... But I still wonder why enable/disable ATA DMA in kernel has no effect for this crash. Why does only the BIOS disable help ? ata-pci0: Unknown PCI ATA controller (generic mode) at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 chip1: PCI to Other bridge (vendor=1022 device=740b) at device 7.3 on pci0 Strange thing is that the the two disks report themselves different (The disks are identical) and the settings in the BIOS for ata0 and ata1 too ... ad0: IBM-DJNA-351520/J56OA30K ATA-4 disk at ata0 as master ad0: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, DMA ^^^ why that ? ad2: IBM-DJNA-351520/J56OA30K ATA-4 disk at ata1 as master ad2: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S ad2: 16 secs/int, 32 depth queue, PIO Anyway, so DMA on K7 boards is not supported. Is someone working on this ? 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: rpc.umntall does not work with AIX [LONG]
Hi, Well, it seems like RPCMNT_UMNTALL call always fails with RPC_SYSTEMERROR on all systems except FreeBSD. I tested HP/UX, AIX and Solaris boxes - they all behave identically as follows: exactly. The other systems reply is 5, which is MNT_IOERR for the authentification handle. I still do not know the reason for this. The call iteslf gets accepted and executed on the remote system. rpc.umntall -h $HOST always fails rpc.umntall -h $HOST -p $DIR - works just fine since it is using RPCMNT_UMOUNT umount $HOST:$DIR works just fine Interesting, even if RPC_UMNTALL call returns error code, it nonetheless causes mount entry to be removed from the server, i.e. showmount -a $HOST output does not report my client machine as having any mounts on $HOST anymore. All entries in my /var/db/mounttab appear to be correct, I do not think they are causing the problem. Also, I have questions regarding the following code fragment from the rpc.umntall.c file: I'll fix this. It seems like it does RPCMNT_UMNTALL call for each mounttab entry regardless of the -k parameter passed in the command line, while man page suggests that it should simply skip entries for currently mounted filesystems. Furthermore, using RPC_UMNTALL in the above loop is probably not a good idea either because client host may have two different directories mounted from the same server. If -k flag is specified, you cannot use UMNTALL because it will remove /var/run/mountdtab entries not only for the mount point left over from the crash but also for all other mounts some of which may be perfectly valid and should be kept intact. I'll add a check for this. Probably it is better to kill use UMNT instead of UMNTALL as you said. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: rpc.umntall does not work with AIX
Bad MNT PRC: RPC: Remote system error Hi, This is a RPC problem, not an NFS problem. Maybe AIX does not support RPC_UMNTALL ? Because our support was buggy, noone may have notified it before. Or do you have problems with the AIX rpc.mountd ? Can you trace mountd(8) on the AIX side and look at the output ? Can you test the following cases too and tell me if it works or not (please umount and mount kan:/home/ak03 again after each command) # rpc.umtall -h kan -p /home/ak03 # rpc.umtall -h kan # umount kan:/home/ak03 What entries do you have in /var/db/mounttab ? 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
Call for objections
Hi everbody, I had a concept to solve some bad implemented NFS part: The client unmount notification of the NFS server. There seems to be different understanding if the programm rpc.umntall should be started at shutdown, startup or both. Can you please vote for or against these three possibilitys ? Someone also had the idea to use a counter 'n' for trying only 'n' times to send a unmount request to the server and then to delete the entry. If we start rpc.umntall at startup-time as the RFC 1813 proposes, we have to save/store all nfs mounts in a list. This may also be some point to discuss. To get an idea you'll have to read the following URL's. my announcement: http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=243597+0+archive/1999/freebsd-hackers/19991114.freebsd-hackers the patches/programm itself: http://www.attic.ch/patches/rpc.umntall/ this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=14709 Thank you very much Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mountpoint locking with fbsd-nfs
On Sun, 1 Aug 1999, Matthew Dillon wrote: Well, theoretically there is nothing wrong going on since you can mount things on top of an NFS directory. Mount only complains about duplicate normal partition mounts because it can't open the buffered block device the second time. NFS doesn't care how many times a directory is imported or exported. Ok, theoretically there may be nothing wrong. But it is just not standard. And what sense could it have to mount on top of an existing mount-point a second time ? This could probably only happen by mistake. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
network got stuck during high nfs-load
Hi driver gurus,
Today I had heavy NFS-load on my CURRENT-SMP machine while compiling
world. Suddenly all NFS-Clients stopped working. I was't able to ping
the server from inside my /29 subnet, same with ping the others from
the server itself. I changed cables, plugged them in and out, did some
ifconfig up down, deleted routes and added them again ... nothing. But
the card was still sending from time to time (once a second) with 100%
load many 0 bytes - like some waves:
(tcp-dump from same subnet, MAC Adress 0:a0:cc:66:32:97 is the NFS-Server)
--
13:53:41.673733 0:a0:cc:66:32:97 0:a0:cc:66:32:97 null test/C len=43
00
13:53:41.773706 0:a0:cc:66:32:97 0:a0:cc:66:32:97 null test/C len=43
00
It looks like a endless loop somewhere in the de0-driver ...
I was able to ping the machine from itself via loopback and via the local
ip. No stucked processes at all, the running make buildworld was still
running. Also the load was normal, I couldn't see some special behaviour ...
I paniced the server and made a crashdump. If anybody is interested in
this strange behaviour, just write me back ... After a reboot, all worked
again, but that's not a good solution ;)
Martin
PS: cvsup is from yesterday (30.7.1999) at 22:00 CET and I included
a backtrace and a dmesg from my server ...
backtrace from debug.kernel
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:291
#1 0xc01538c9 in panic (fmt=0xc0277c14 "from debugger")
at ../../kern/kern_shutdown.c:505
#2 0xc012df19 in db_panic (addr=-1071398025, have_addr=0, count=-1,
modif=0xff80dddc "") at ../../ddb/db_command.c:434
#3 0xc012deb7 in db_command (last_cmdp=0xc02a6f30, cmd_table=0xc02a6d90,
aux_cmd_tablep=0xc02c572c) at ../../ddb/db_command.c:334
#4 0xc012df7e in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc012ffbb in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc023c0c2 in kdb_trap (type=3, code=0, regs=0xff80ded0)
at ../../i386/i386/db_interface.c:157
#7 0xc02524a0 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = -1070741376, tf_ebp = -8331496, tf_isp = -8331524,
tf_ebx = -1070741376, tf_edx = -1070689184, tf_ecx = 16777217,
tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071398025, tf_cs
= 8,
tf_eflags = 582, tf_esp = -1071030749, tf_ss = -1071045718})
at ../../i386/i386/trap.c:534
#8 0xc023c377 in Debugger (msg=0xc02923aa "manual escape to debugger")
at machine/cpufunc.h:64
#9 0xc0236d7c in scgetc (sc=0xc02c3ca0, flags=2)
at ../../dev/syscons/syscons.c:3813
#10 0xc0232529 in sckbdevent (thiskbd=0xc02db0a0, event=0, arg=0xc02c3ca0)
at ../../dev/syscons/syscons.c:688
#11 0xc022bd77 in atkbd_intr (kbd=0xc02db0a0, arg=0x0)
at ../../dev/kbd/atkbd.c:535
#12 0xc02692d7 in atkbd_isa_intr (arg=0xc05a2100) at
../../isa/atkbd_isa.c:125
dmesg-output
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 #1: Fri Jul 30 21:31:06 CEST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/FUCHUR
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P55C (586-class CPU)
Origin = "GenuineIntel" Id = 0x543 Stepping = 3
Features=0x8003bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,MMX
real memory = 67108864 (65536K bytes)
avail memory = 61652992 (60208K bytes)
Programming 24 pins in IOAPIC #0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0
cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc034.
Intel Pentium detected, installing workaround for F00F bug
Probing for PnP devices:
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
pci0: PCI bus on pcib0
isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0
ide_pci0: Intel PIIX3 Bus-master IDE controller at device 7.1 on pci0
de0: Digital 21140A Fast Ethernet irq 17 at device 9.0 on pci0
de0: 21140A [10-100Mb/s] pass 2.0
de0: address 00:a0:cc:66:32:97
vga-pci0: Matrox MGA 1024SG/1064SG/1164SG graphics accelerator irq 18 at
device 10.0 on pci0
ahc0: Adaptec aic7880 Ultra SCSI adapter irq 19 at device 12.0 on pci0
ahc0: Using left over BIOS settings
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
isa0: ISA bus on motherboard
fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO
ed0: device timeout
Hi, Maybe current is not the right one to send my problem to - but I'm not subscribed on freebsd.mobile. Recently I bought a new laptop and my ed0-pccard stopped working. This happened before the newconfig stuff came in. I first thought there were some irq-related problems, but I wasn't able to figure out where the problems are. The pccard-controller is now on irq 3 (SIO1 is disabled). I also tried to put it on irq 9 or 10 with set machdep.pccard.pcic_irq, after I disabled the soundcard. That worked, but the result was the same. Is suppose that the irq's aren't as free they should be. I tried other io-settings, other irq's, the result was the same. Curious: A 2.2.8 PA0 system worked on this Laptop without problems, the card gets recognized and no timeouts appeared at all. Any help is welcome. I've no idea what my problem could be. some dmsg-output from fresh kernel: --- chip0: Intel 82439TX System Controller (MTXC) at device 0.0 on pci0 isab0: Intel 82371AB PCI to ISA bridge at device 1.0 on pci0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 1.1 on pci0 uhci0: Intel 82371AB/EB (PIIX4) USB Host Controller at device 1.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB Host Controller on uhci0 chip1: Intel 82371AB Power management controller at device 1.3 on pci0 chip2: PCI to CardBus bridge (vendor=104c device=ac16) at device 3.0 on pci0 chip3: PCI to CardBus bridge (vendor=104c device=ac16) at device 3.1 on pci0 PC-Card VLSI 82C146 (5 mem 2 I/O windows) pcic: controller irq 3 Initializing PC-card drivers: ed Card inserted, slot 0 ed0: address 00:c0:f0:1c:b8:20, type NE2000 (16 bit) ed0: device timeout ed0: device timeout ed0: device timeout ed0: device timeout dmesg | grep irq: - uhci0: interrupting at irq 11 fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: interrupting at irq 14 wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: interrupting at irq 15 atkbd0: interrupting at irq 1 psm0: interrupting at irq 12 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: interrupting at irq 4 ppc0 at port 0x378 irq 7 on isa0 ppc0: interrupting at irq 7 pcic: controller irq 3 cat /dev/sndstat : - OPL-2/OPL-3 FM at 0x388 SoundPort at 0x534 irq 5 drq 1,3 MPU-401 (UART) at 0x320 irq 9 /etc/pccard.conf : -- # Generally available IO ports io 0x280 - 0x2F0 0x300 - 0x360 # Generally available IRQs (Built-in sound-card owners remove 5) irq 5 9 10 # Available memory slots memory 0xd4000 96k memory 0xc4000 32k # Kingston Ethernet card card Kingston KNE-PC2 config 0x22 ed0 10 insert echo Kingston card inserted insert /etc/pccard_home ed0 remove echo Kingston card removed remove /sbin/ifconfig ed0 delete kernel-konfig: -- # PCCARD (PCMCIA) support controller card0 device pcic0 at card? device pcic1 at card? device ed0 altern. kernel-konfig: -- controller card0 device pcic0 at card? device pcic1 at card? device ed0 at isa? port 0x340 net irq 10 iomem 0xd8000 pccardc dumpcis: Configuration data for card in slot 0 Tuple #1, code = 0x1 (Common memory descriptor), length = 2 000: 00 ff Common memory device information: Device number 1, type No device, WPS = OFF Speed = No speed, Memory block size = reserved, 32 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 000: 49 00 ff Attribute memory device information: Device number 1, type EEPROM, WPS = ON Speed = 250nS, Memory block size = 512b, 1 units Tuple #3, code = 0x20 (Manufacturer ID), length = 4 000: 86 01 00 01 PCMCIA ID = 0x186, OEM ID = 0x100 Tuple #4, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #5, code = 0x15 (Version 1 info), length = 21 000: 04 01 4b 69 6e 67 73 74 6f 6e 00 4b 4e 45 2d 50 010: 43 32 00 00 ff Version = 4.1, Manuf = [Kingston],card vers = [KNE-PC2] Addit. info = [] Tuple #6, code = 0x1a (Configuration map), length = 5 000: 01 23 f8 03 03 Reg len = 2, config register addr = 0x3f8, last config = 0x23 Registers: XX-- Tuple #7, code = 0x1b (Configuration entry), length = 21 000: e0 81 1d 3f 55 4d 5d 06 86 46 26 fc 24 c5 60 00 010: 03 1f 30 b8 9e Config index = 0x20(default) Interface byte = 0x81 (I/O) wait signal supported Vcc pwr: Nominal operating supply voltage: 5 x 1V Minimum operating supply voltage: 4.5 x 1V Maximum operating supply voltage: 5.5 x 1V Continuous supply current: 1 x 100mA Max current average over 1 second:
RE: new panic from fresh current (SMP)
Hi, It seems to be fixed now with v 1.97 from /usr/src/sys/i386/i386/mp_machdep.c thanks ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new panic from fresh current (SMP)
But it's not related to that caused by the NMI, and it appears suddenly after probing soerens ATAPI drivers. hmm - SMP: AP CPU #1 Launched! does not appear ... what this ever means. the previos kernel as of yesterday had: IP Filter: initialized. Default = pass all, Logging = disabled SMP: AP CPU #1 Launched! acd0: CDROM drive at ata0 as master acd0: drive speed 5512KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked afd0: rewriteable drive at ata0 as slave afd0: 96MB (196608 sectors), 32 cyls, 64 heads, 96 S/T, 512 B/S afd0: Unknown media (0x0) Waiting 5 seconds for SCSI devices to settle now the panic ... mp_lock = 011; cpuid = 1; lapic.id = 010 instruction pointer = 0x8:0xc024bfb8 stack pointer = 0x10:0xff804ff8 frame pointer = 0x10:0x0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = Idle interrupt mask = - SMP: XXX kernel: type 29 trap, code=0 Stopped at default_halt: ret db no trace Martin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new panic from fresh current (SMP)
aeh - forgot to say ... it is reproducable - it can't boot And the kernel-gdbtrace isn't very useful :( Martin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Panic from today's current
While running a make 'buildworld -j 10', my SMP box crashed. I had a running nfs-server and softupdates enabled when it happened. The kernel-configfile and dmesg-output is available from: http://www.attic.ch/fuchur_kernel.html panic at: generic_bcopy+0x1arepe movsl (%esi), %es:(%edi) db trace generic_bcopy(c02cc380,c7bb9b1f,0,a,0) at generic_bcopy+0x1a sccnputc(cff,1,c7bb9b80,c016c066) at sccnputc+0x180 cnputc(a,0,0,a,c7bb9bcc) at cnputc+0x3d putchar(a,c7bb9bf0) at putchar+0xa6 kvprintf(c028da63,c016bfc0,c7bb9bf0,a,c7bb9c04) at kvprintf+0x64 printf(c028da49,8000,c1159b00,a8,c7bc3e60) at printf+0x3d trap(10,10,a8,c1159b00,c7bb9ce8) at trap+0x462 calltrap() at calltrap+0x3c --- trap 0x13, eip = 0xc7bb9c68, ebp = 0xc7bb9ce8 --- ufs_lookup(c7bb9d2c,c7bb9d40,c0184946,c7bb9d2c,c79ba00e) at ufs_lookup+0x353 ufs_vnoperate(c7bb9d2c,c79ba00e,c746e580,c7bb9f10,c746e580 at ufs_vnoperate+0x15 vfs_cache_lookup(c7bb9d84,c7bb9d94,c0186d2b,c7bb9d84,c7470e00) at vfs_cache_lookup+0x26a ufs_vnoperate(c7bb9d84,c7470e00,c7bb9f10,c1303a00,0) at ufs_vnoperate+0x15 lookup(c7bb9eec,0,c7bb9f84,fffc,c7b757f0) at lookup+0x2af namei(c7bb9eec,0,c7bb9f84,fffc,c02df240) at namei+0x291 vn_open(c7bb9eec603,1a4c7bc3e60,c029d3f0) at vn_open+0x59 open(c7bc3e60,c7bb9f84,8070aa0,10,8085680) at open+0xbb syscall(2f,2f,8085680,10,bfbfcb84) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x4c It seams to be ufs-related. Does anybody know what happened ? Martin Martin Blapp, mbl...@solnet.ch -- SolNet, Internet Solution Provider Bechburgstrasse 29, 4528 Zuchwil, Switzerland Phone: +41 32 686 82 82, Fax: +41 32 685 96 13 -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Bug with afd0 (zip-drive)
Hi, I have the same problems with Soren's new ATA driver: fuchur# mount_msdos -o noauto /dev/afd0s4 /zip mount_msdos: /dev/afd0s4: Invalid argument With the old driver and slice wfd0s4, this worked with msdos formatted zip-mediums. kernel konfig: -- controller ata0 device atadisk0# ATA disk drives device atapicd0# ATAPI CDROM drives device atapifd0# ATAPI floppy drives I've removed the old wdc* controller- and device- options completly. dmesg output with the old driver: - wdc1: unit 1 (atapi): IOMEGA ZIP 100 ATAPI/23.D, removable,intr,iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set dmesg output with the new driver: - (cvsup from 3 Apr) FreeBSD 4.0-CURRENT #6: Sat Apr 3 17:14:27 CEST 1999 r...@fuchur.lan.attic.ch:/usr/src/sys/compile/FUCHUR ... ... acd0: TOSHIBA CD-ROM XM-6202B/1110 CDROM drive at ata0 as master acd0: drive speed 5512KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked afd0: IOMEGA ZIP 100 ATAPI/23.D rewriteable drive at ata0 as slave afd0: 96MB (196608 sectors), 32 cyls, 64 heads, 96 S/T, 512 B/S afd0: Unknown media (0x0) Hi, I'm not able to use msdos disks with afd0. It isn't usable with the mtools too (yes, I've used MAKEDEV to make the needed dev-nodes). cvsup at 7pm CET. not able to use: mdir z: init Z: non DOS media Cannot initialize 'Z:' mount /zip msdos: /dev/afd0s4: Invalid argument Am I missing something? Bye, Alexander. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Looks broken to me...
Only if you make world with -j x ... without -j it's working. make buildworld -j10 /tmp/build.out 21 breaks the same time making the cc_tools : `gencheck.c' is up to date. `c-parse.in' is up to date. `gencheck.c' is up to date. `c-parse.in' is up to date. === cc_int make: don't know how to make insn-attrtab.c. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
