Re: Kerberized NFSv3 incorrect behavior
On 6 Feb 2010, at 09:44, George Mamalakis wrote: > Rick Macklem wrote: >> >> >> On Fri, 5 Feb 2010, George Mamalakis wrote: >> >>> Dear all, >>> >>> I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My >>> configuration is based on >>> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal >>> is to share filesystems securely through kerberos authentication. >>> Everything works fine, until I try to kdestroy my tickets or kinit to some >>> other user, where the system insists to think that I am the user that >>> initially obtained their ticket. To be more extensive, my story is as >>> follows: >>> >> [good stuff snipped] >>> >>> >>> and both client and server have the correct entries about each other (and >>> themselves) in their /etc/hosts, so heimdal works just fine. >>> >>> Both client and server have their respective keytabs stored in >>> /etc/krb5.keytab, and I use two users in my example (that both exist in >>> both systems with the same uid,gid): mamalos and testakis. >>> >> >> Unless you have applied the experimental patch, a keytab entry is >> meaningless in the client. Without that, it was assumed that "root" >> would never "kinit" as anyone. Basically, it was assumed that "root" >> would only do the mount and a user, like "mamalos" or "testakis" >> would be logged in and kinit'd as that user. >> >> The short answer is that any principal with TGT in the credentials >> cache for uid==N will be used to authenticate that user. Once >> authenticated, that "handle" for the user can be used until it >> expires (up to the server, but usually set to when the TGT that >> it found in the credential cache is due to expire). >> >>> So, when I mount the exported filesystem on the client giving: >>> >>> # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt >>> # mount >>> /dev/da0s1a on / (ufs, local, soft-updates) >>> devfs on /dev (devfs, local, multilabel) >>> server.example.com:/exports on /mnt (nfs) >>> >>> and try to access the share: >>> # ls /mnt >>> ls: mnt: Permission denied >>> >>> I get the error I am expecting, since root does not have any kerberos >>> tickets assigned, yet. Let's see what happens when I kinit as mamalos: >> >> Yep, as expected. >>> # klist >>> Credentials cache: FILE:/tmp/krb5cc_0 >>> Principal: mama...@example.com >>> >>> Issued Expires Principal >>> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/exapmle@example.com >>> # ls -la /mnt/ >>> total 8 >>> drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ >>> drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ >>> drwx-- 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ >>> drwx-- 2 testakis wheel - 512 4 Feb 19:06 testakis/ >>> # touch /mnt/mamalos/myfile >>> # ls -la /mnt/mamalos/myfile >>> rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile >>> >>> Which is the exact behavior that is expected. Now when I kdestroy: >>> # kdestroy >>> # klist >>> klist: No ticket file: /tmp/krb5cc_0 >>> # touch /mnt/mamalos/myfilethatshouldnotbe >>> # ls -la /mnt/mamalos/myfilethatshouldnotbe >>> -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 >>> /mnt/mamalos/myfilethatshouldnotbe >>> >> >> Yes, this is a "bug/limitation" in the current implementation. I believe >> that "kdestroy" should do some sort of system call to inform the NFS >> client that "credentials for uid==N" should be invalidated. This is not >> implemented in FreeBSD8 (or Linux for that matter, last I checked). >> I don't know if dfr@ was planning on doing this and whether or not he >> thinks it is appropriate to do so? >> >> Without that implemented, the "handle" continues to work until the >> server expires it, normally when the TGT for "mamalos" would have >> expired if you hadn't kdestroy'd it. >> >>> And I can do everything in that share as if I were still mamalos, even >>> though I kdestroyed my kerberos ticket. The same thing will happen even if >>> I kinit to testakis after that. klist shows testakis' ticket this time, but >>> I am not allowed to access (rwx) tetakis' files/folders, and I still have >>> full control over mamalos' files and folders. >>> >>> In order to be able to do something as testakis, I have to unmount the >>> share and remount it while having testakis' ticket (or having no ticket at >>> all, and giving kinit testakis after mounting the share). >>> >> >> Actually, logging in as "testakis" should allow that user to access the >> mount as "testakis" once kinit'd as "testakis". The trick is that the >> credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the >> uid assigned to "testakis"). Same would apply to "mamalos" if that >> user were logged in with a non-0 uid. >> >>> I am not an NFS expert, but I suppose that this behavior is not the one to >>> be expected, except if I am missing some fundamental information about >>> kerberized NFS that explains it. Even so, it would be quite unwise to >>> behave so, since even if the users kdestroys their tickets, they have s
Re: lock problem: nfs server on FreeBSD 7-stable, client on linux
On 6 Apr 2008, at 07:38, Tz-Huan Huang wrote: On Sun, Apr 6, 2008 at 2:05 PM, Rong-en Fan <[EMAIL PROTECTED]> wrote: On Sun, Apr 6, 2008 at 1:18 PM, Tz-Huan Huang <[EMAIL PROTECTED]> wrote: Hi, Thanks for your suggestion, but we don't accept this workaround. After doing binary searching, I find that this commit break the working lockd: http://lists.freebsd.org/pipermail/cvs-src/2008-March/089037.html I have rolled back the lockd.c to 1.20 in our nfs server and it works fine as before. Add dfr@ to CC list. I'm curious about this change, could you check what socket bind by rpc.lockd and rpc.statd before and after lockd. rev 1.21+1.22 changes? Ok, following is the output of sockstat -4l : Before the changes: daemon rpc.lockd 83002 3 udp4 *:677 *:* daemon rpc.lockd 83002 4 tcp4 *:946 *:* daemon rpc.lockd 83002 7 udp4 *:642 *:* root rpc.lockd 83001 3 udp4 *:677 *:* root rpc.lockd 83001 4 tcp4 *:946 *:* root rpc.lockd 83001 7 udp4 *:642 *:* root rpc.statd 973 3 udp4 *:964 *:* root rpc.statd 973 4 tcp4 *:602 *:* After the changes: (with -h 140.112.29.133) daemon rpc.lockd 82817 4 udp4 127.0.0.1:696 *:* daemon rpc.lockd 82817 5 udp4 140.112.29.133:696*:* daemon rpc.lockd 82817 6 tcp4 127.0.0.1:696 *:* daemon rpc.lockd 82817 7 tcp4 140.112.29.133:696*:* daemon rpc.lockd 82817 9 udp4 *:974 *:* root rpc.lockd 82816 4 udp4 127.0.0.1:696 *:* root rpc.lockd 82816 5 udp4 140.112.29.133:696*:* root rpc.lockd 82816 6 tcp4 127.0.0.1:696 *:* root rpc.lockd 82816 7 tcp4 140.112.29.133:696*:* root rpc.lockd 82816 9 udp4 *:974 *:* root rpc.statd 973 3 udp4 *:964 *:* root rpc.statd 973 4 tcp4 *:602 *:* (without -h 140.112.29.133) daemon rpc.lockd 82541 4 udp4 *:915 *:* daemon rpc.lockd 82541 5 tcp4 *:915 *:* daemon rpc.lockd 82541 7 udp4 *:713 *:* root rpc.lockd 82540 4 udp4 *:915 *:* root rpc.lockd 82540 5 tcp4 *:915 *:* root rpc.lockd 82540 7 udp4 *:713 *:* root rpc.statd 973 3 udp4 *:964 *:* root rpc.statd 973 4 tcp4 *:602 *:* More information would be provided if necessary. It would be useful to get a packet trace from tcpdump (e.g. tcpdump -w ) that shows what happens on the wire when the linux client fails to lock a file on the freebsd server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lock problem: nfs server on FreeBSD 7-stable, client on linux
On 6 Apr 2008, at 09:58, Tz-Huan Huang wrote: On Sun, Apr 6, 2008 at 3:45 PM, Doug Rabson <[EMAIL PROTECTED]> wrote: It would be useful to get a packet trace from tcpdump (e.g. tcpdump -w ) that shows what happens on the wire when the linux client fails to lock a file on the freebsd server. Since the nfs server is in production now, I have setup another machine to get the packet trace. Here is the output of tcpdump (I use tcpdump -w host cml8): http://w.csie.org/~tzhuan/tmp/tcpdump.raw Could you possibly try again with 'tcpdump -w -s 1500' - the packets were truncated which made it difficult to analyse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lock problem: nfs server on FreeBSD 7-stable, client on linux
On 6 Apr 2008, at 09:58, Tz-Huan Huang wrote: On Sun, Apr 6, 2008 at 3:45 PM, Doug Rabson <[EMAIL PROTECTED]> wrote: It would be useful to get a packet trace from tcpdump (e.g. tcpdump -w ) that shows what happens on the wire when the linux client fails to lock a file on the freebsd server. Since the nfs server is in production now, I have setup another machine to get the packet trace. Here is the output of tcpdump (I use tcpdump -w host cml8): http://w.csie.org/~tzhuan/tmp/tcpdump.raw cml7 is the nfs server (today's 7-stable, i386) and cml8 is debian linux (amd64). I use this program (http://w.csie.org/~tzhuan/tmp/lock.c) to test the file locking when capturing the packets. It ran about 1m30s and showed ``lock fail''. One thing I did notice is that the client appears to be trying to connect to the server on tcp port 751 and the server is rejecting that connection. I'm not sure I trust the output of sockstat - could you show me the output of rpcinfo and netstat -an. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lock problem: nfs server on FreeBSD 7-stable, client on linux
On 6 Apr 2008, at 11:30, Tz-Huan Huang wrote: On Sun, Apr 6, 2008 at 5:21 PM, Doug Rabson <[EMAIL PROTECTED]> wrote: Could you possibly try again with 'tcpdump -w -s 1500' - the packets were truncated which made it difficult to analyse. Sure, it's available here: http://w.csie.org/~tzhuan/tmp/tcpdump2.raw Hmm. Somehow the socket which rpc.lockd is supposed to use for accepting TCP requests has been closed. Linux tends to use TCP for lock requests when the NFS is mounted over TCP. I'll try and reproduce this locally. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lock problem: nfs server on FreeBSD 7-stable, client on linux
On 6 Apr 2008, at 11:48, Tz-Huan Huang wrote: On Sun, Apr 6, 2008 at 5:53 PM, Doug Rabson <[EMAIL PROTECTED]> wrote: One thing I did notice is that the client appears to be trying to connect to the server on tcp port 751 and the server is rejecting that connection. I'm not sure I trust the output of sockstat - could you show me the output of rpcinfo and netstat -an. Here you are: http://w.csie.org/~tzhuan/tmp/rpcinfo.txt http://w.csie.org/~tzhuan/tmp/netstat.txt This patch should fix the problem. Sorry for the inconvenience. lockd.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic with smbfs after MFC of kernel space locking
On 14 Apr 2008, at 08:19, Oliver Brandmueller wrote: Hello and good morning, I upgraded to 7-STABLE after the MFC of the kernel space locking. Since then I experience panics with programs that strongly rely in file locking on CIFS (smbfs) mounts: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x13bf2a8 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8023305a stack pointer = 0x10:0xc72d7920 frame pointer = 0x10:0xc72d7950 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 42037 (perl) [thread pid 42037 tid 100124 ] Stopped at lf_getblock+0x2a: cmpq%r12,0x8(%rbx) db> bt Tracing pid 42037 tid 100124 td 0xff00037dc350 lf_getblock() at lf_getblock+0x2a lf_advlockasync() at lf_advlockasync+0x4f5 lf_advlock() at lf_advlock+0x47 smbfs_advlock() at smbfs_advlock+0x19a flock() at flock+0x150 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (131, FreeBSD ELF64, flock), rip = 0x800c0a3fc, rsp = 0x7fffecc8, rbp = 0x8325e8 --- As far as I can see there were changes for all kinds of file systems with the MFC, but no change in the smbfs filesystem. I also couldn't find any change in HEAD's smbfs, so it was not a missing MFC, but probably the fs was missed in the changes at all. Could anyone with a little better programming skills than me probably have a look at it? From the diffs of the other filesystems it seems like it's not a real big change, but mainly adding the function. I added a new vnode operation to support the new lock manager but this operation only needs to be implemented on filesystems that can be exported via NFS. I assumed that this was not the case for SMBFS. Could you find me a line number for lf_getblock+0x2a - something like this should do it: # gdb /boot/kernel/kernel (gdb) l *(lf_getblock+0x2a) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: samba build failure on 6-STABLE
On 1 May 2008, at 15:39, Michael Proto wrote: Greg Byshenk wrote: I'm posting this to freebsd-stable even though it is a problem with a port, because the port itself has not changed, but a rebuild fails (on a system and with a configuration that worked before my most recent system updates). Basically my problem is that the current Samba3 (samba-3.0.28,1) won't build on a recent 6-STABLE system (I noticed it with sources csup'd 24 April, and it continues with sources csup'd today, 1 May). The strange thing is that this is a version of samba that has previously built successfully, on the machine and with the configuration that is now failing. (I was attempting to rebuild because I saw some strange library errors.) This at least suggests to me that the problem is _not_ due to something changing with Samba, but to some other change that is being reflected in the Samba build. The system in question is built from sources csup'd today (1 May 2008), with all installed ports current as of today. The same Samba did build successfully with a source and ports tree csup'd on 7 March 2008. As a test to see if there is some problem with the ports dependencies, I've tried a 'portupgrade -fR samba'; all of the dependencies built fine, but then I got the same error when attempting to build Samba itself. It is not definitive, but this suggests to me that this is not a ports problem (per se), but a kernel/world problem. This latter is highlighted by the fact that Samba builds without error on a system with sources csup'd on 17 April. That is, if I take the exact same system on which the build fails, revert my world/kernel to a build from 17 April (leaving everything else exactly the same), then the error disappears and Samba builds successfully. The actual error is below. Any ideas are welcome. I have a machine that I can play with if someone would like me to try anything. -greg Compiling smbd/oplock_linux.c smbd/oplock_linux.c: In function `signal_handler': smbd/oplock_linux.c:73: error: structure has no member named `si_fd' The following command failed: cc -I. -I/usr/ports/net/samba3/work/samba-3.0.28/source -O2 -fno- strict-aliasing -pipe -D_SAMBA_BUILD_=3 -I/usr/local/include -I/ usr/ports/net/samba3/work/samba-3.0.28/source/iniparser/src - Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc -I./ tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H -I/usr/local/ include -DLDAP_DEPRECATED-I/usr/ports/net/samba3/work/ samba-3.0.28/source/lib -D_SAMBA_BUILD_=3 -fPIC -DPIC -c smbd/ oplock_linux.c -o smbd/oplock_linux.o *** Error code 1 Stop in /usr/ports/net/samba3/work/samba-3.0.28/source. *** Error code 1 Stop in /usr/ports/net/samba3. *** Error code 1 Stop in /usr/ports/net/samba3. I can confirm this on a 6-STABLE system last SUPed (kernel and world rebuilt) to 20080428 11:23 EDT. samba-3.0.28,1 built fine on this box when it was 6.3-RELEASE, and now fails in exactly the same place when trying to rebuild on 6-STABLE. The attached patch should fix the problem syscall.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: samba build failure on 6-STABLE
On 3 May 2008, at 18:23, Greg Byshenk wrote: On Sat, May 03, 2008 at 11:42:14AM +0100, Doug Rabson wrote: On 1 May 2008, at 15:39, Michael Proto wrote: Greg Byshenk wrote: [...] Basically my problem is that the current Samba3 (samba-3.0.28,1) won't build on a recent 6-STABLE system (I noticed it with sources csup'd 24 April, and it continues with sources csup'd today, 1 May). The strange thing is that this is a version of samba that has previously built successfully, on the machine and with the configuration that is now failing. (I was attempting to rebuild because I saw some strange library errors.) This at least suggests to me that the problem is _not_ due to something changing with Samba, but to some other change that is being reflected in the Samba build. [...] I can confirm this on a 6-STABLE system last SUPed (kernel and world rebuilt) to 20080428 11:23 EDT. samba-3.0.28,1 built fine on this box when it was 6.3-RELEASE, and now fails in exactly the same place when trying to rebuild on 6-STABLE. The attached patch should fix the problem. It appears that it does. I've applied the patch on a test machine, and Samba now builds successfully. I've also done a reinstall of Samba, and the rebuild version appears to be working properly (though I have not yet done any extensive testing). Great, thanks for testing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flock incorrectly detects deadlock on 7-stable and current
On 8 May 2008, at 09:12, Paul Koch wrote:
Hi,
We have been trying to track down a problem with one of our apps which
does a lot of flock(2) calls. flock returns errno 11 (Resource
deadlock avoided) under certain scenarios. Our app works fine on
7-Release, but fails on 7-stable and -current.
The problem appears to be when we have at least three processes doing
flock() on a file, and one is trying to upgrade a shared lock to an
exclusive lock but fails with a deadlock avoided.
Attached is a simple flock() test program.
a. Process 1 requests and gets a shared lock
b. Process 2 requests and blocks for an exclusive lock
c. Process 3 requests and gets a shared lock
d. Process 3 requests an upgrade to an exclusive lock but fails (errno
11)
If we change 'd' to
Process 3 requests unlock, then requests exclusive lock, it works.
Could you possibly try this patch and tell me if it helps:
//depot/user/dfr/lockd/sys/kern/kern_lockf.c#57 - /tank/projects/
lockd/src/sys/kern/kern_lockf.c
@@ -1370,6 +1370,18 @@
}
/*
+* For flock type locks, we must first remove
+* any shared locks that we hold before we sleep
+* waiting for an exclusive lock.
+*/
+ if ((lock->lf_flags & F_FLOCK) &&
+ lock->lf_type == F_WRLCK) {
+ lock->lf_type = F_UNLCK;
+ lf_activate_lock(state, lock);
+ lock->lf_type = F_WRLCK;
+ }
+
+ /*
* We are blocked. Create edges to each blocking lock,
* checking for deadlock using the owner graph. For
* simplicity, we run deadlock detection for all
@@ -1389,17 +1401,6 @@
}
/*
-* For flock type locks, we must first remove
-* any shared locks that we hold before we sleep
-* waiting for an exclusive lock.
-*/
- if ((lock->lf_flags & F_FLOCK) &&
- lock->lf_type == F_WRLCK) {
- lock->lf_type = F_UNLCK;
- lf_activate_lock(state, lock);
- lock->lf_type = F_WRLCK;
- }
- /*
* We have added edges to everything that blocks
* us. Sleep until they all go away.
*/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flock incorrectly detects deadlock on 7-stable and current
On 9 May 2008, at 07:07, Paul Koch wrote: On Thu, 8 May 2008 06:37:00 pm Doug Rabson wrote: Could you possibly try this patch and tell me if it helps: ... Manually applied the patch to stable kern_lockf.c 1.57.2.1. Ran the flock_test program on many of our architectures and it works fine. Have also been testing our app on a single core i386 machine today with no locking problems. Just setup a quad core -stable amd64 build and it also appears to be running fine now. Thanks for that. I'll get the patch committed to current today - it will turn up in 7-stable in a couple of days. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? On 19 May 2008, at 16:17, Dave Uhring wrote: Sources checked out yesterday, updated this morning using cvsup and repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/ libc /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/ usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/ src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../ contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/ libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES - DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING - DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno- uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't known /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier is reported only once /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it appears in.) /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no member named 'l_sysid' /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED] " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 19 May 2008, at 17:38, Dave Uhring wrote: On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. You should never have to copy any header files to /usr/include to get a buildworld to work. Try without the -DNO_CLEAN and if that still fails, clean your /usr/obj (e.g. with rm -rf /usr/obj/*). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 19 May 2008, at 17:58, Dave Uhring wrote: On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( The thing is that a working buildworld doesn't depend on headers from / usr/include. One of the first thing it does is install a set of new headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be useful to see a log of a failed buildworld attempt to see what is going wrong. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 20 May 2008, at 01:02, Dave Uhring wrote: On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: On May 19, 2008, at 1:21 PM, Dave Uhring wrote: In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. I did not have to manually move or copy any header files. *default release=cvs tag=RELENG_7 My build on that, csupped just after seeing your first message in this thread, has just completed. make buildworld worked just fine without error. I'm also on athlon64. All the headers that I needed were in the right places in /usr/src Did you start from a RELEASE source tree and userland? So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: 'asm' operand has impossible constraints In this, your build is explicitly using '/usr/bin/gcc' for the build which is not the way buildworld normally works. In normal operation, buildworld first builds a compiler from source and then uses that compiler by adding to $PATH and building with just 'cc'. Are you overriding $CC in your environment? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 20 May 2008, at 14:31, Dave Uhring wrote: On Tue, May 20, 2008 at 12:54:59PM +0100, Doug Rabson wrote: On 20 May 2008, at 12:25, Dave Uhring wrote: On Tue, May 20, 2008 at 08:50:14AM +0100, Doug Rabson wrote: In this, your build is explicitly using '/usr/bin/gcc' for the build which is not the way buildworld normally works. In normal operation, buildworld first builds a compiler from source and then uses that compiler by adding to $PATH and building with just 'cc'. Are you overriding $CC in your environment? I did not even have $CC in my environment. My environment had absolutely nothing involving the compiler and the compiler was the one shipped with FreeBSD-7.0-RELEASE. It is the *only* compiler on the system. Odd. Could you please send me the complete log of a failed build attempt. I did not maintain such a log. On that last build everything proceeded normally until it broke in an inline assembler piece of code. But I published not only the error but also the previous 4 or 5 compile lines. I'm building again with a virgin clean cvsupped source tree from cvsup4.freebsd.org, a clean /usr/obj, and I have reverted to /bin/ csh for my root shell if that can possibly matter. /etc/make.conf sets the build shell as /bin/sh. This time I started the build using script. The entire log will be available. Excellent. Thanks for your help tracking this down. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs buildworld blocked by rpc.lockd ?
On 28 May 2008, at 20:57, Arno J. Klaassen wrote: Hello, my buildworld on a 7-stable-amd64 blocks on the following line : TERM=dumb TERMCAP=dumb: ex - /files/bsd/src7/share/termcap/ termcap.src < /files/bsd/src7/share/termcap/reorder ex(1) stays in lockd state, and is unkillable, either by Ctl-C or kill -9 /files/bsd is nfs-mounted as follows : push:/raid1/bsd/files/bsd nfs rw,bg,soft,nfsv3,intr,noconn,noauto,-r=32768,-w=32768 0 0 I can provide tcpdumps on server and client if helpful. I would very much like to see tcpdumps (from either client or server). This problem is often caused by the fact that unless you use the '-p' flag, rpc.lockd isn't wired down to any particular port number. Since it is started at boot time, it will usually end up with the same one each time but the new kernel implementation in 7-stable typically ends up with a different port number to the old userland implementation. Quirks of the locking protocol make it difficult for the server to notice this without a lengthy timeout. Workarounds include using '-p' to wire it down to a consistent port (port 4045 is reserved for this) or restarting rpc.lockd on the server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: default dns config change causing major poolpah
On Wed, 2007-08-01 at 18:04 -1000, Randy Bush wrote: > > in addition nowhere does it state in RFC2870 that the root-servers have to > > accept AXFR's as part of their service. > > in fact, the opposite > >2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, >queries from clients other than other root servers. This >restriction is intended to, among other things, prevent >unnecessary load on the root servers as advice has been heard >such as "To avoid having a corruptible cache, make your server a >stealth secondary for the root zone." The root servers MAY put >the root zone up for ftp or other access on one or more less >critical servers. I think this makes it completely clear that we should not be trying to use the AXFR service from any of the root servers. Expert users can do what they like but making our default configuration use a service which is documented in the current best practices document as being unsupported seems foolish. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS boot on zfs mirror
On Tue, 26 May 2009 19:57:03 +0300, Andriy Gapon wrote: > on 26/05/2009 19:42 George Hartzell said the following: >> I'm still confused about the two parts of zfsboot and what's magical >> about seeking to 1024. > > Can't help with answer to this, but cc-ing the one who can (I think). > I am interested too :-) This is due to the primitive DOS boot sequence. Basically the BIOS loads the first sector of the partition and executes it. For zfsboot, that is the first 512 bytes of /boot/zfsboot. The next stage of the bootstrap is tucked away in a convenient hole in the ZFS on-disk formwat which is located just after the ZFS metadata - this is the seek=1024 part. The first 512 byte part is a tiny assembler program that loads the rest into memory and executes it. The second part is large enough and smart enough to understand the ZFS filesystem format directly and it loads /boot/loader directly from the filesystem and transfers control to that. The third stage (/boot/loader) is what puts up the boot menu and loads the kernel etc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /boot/loader can't load kernel if too many pool/devices
On 1 Jun 2009, at 11:22, Henri Hennebert wrote: Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error "can't boot 'kernel'" if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/ loader from 8.0-CURRENT. I recently increased the number of file descriptors available for / boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: AMD64 + Nvidia Display Card
On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: > On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: > > On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: > > > Quoting Brett Wildermoth <[EMAIL PROTECTED]>: > > > > To all my fellow FreeBSD users, > > > > > > > > I assume I am not the only one who is in this predicament. I > > > > have just bought seven AMD 64s with NVIDIA PCI-X graphics. With > > > > 5.4 I can get everything bar the network and X to work, with > > > > 6.0 I can get the network to work also. However no matter what > > > > I do I can't get X to work. > > > > > > > > Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. > > > > They make one for > > > > Linux x86-64 and one for FreeBSD-x86. > > > > > > > > Perhaps would could all post a message on nvforum. I see some > > > > people already have. > > > > > > > > Perhaps NVIDIA think FreeBSD is just a hobby OS.. > > > > > > Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. > > > Just post that > > > you're pissed about it like the rest of us are... maybe they'll > > > reconsider. > > > > Not true. FreeBSD's kernel doesn't provide some things needed for > > an amd64 driver to be feasible. > > Like what what are these features? and if they are really > important why aren't they on the cards to be included into > FreeBSD.. There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 + Nvidia Display Card
On 14 Jul 2005, at 11:06, Brett Wildermoth wrote: On Thu, 14 Jul 2005 07:07 pm, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: Quoting Brett Wildermoth <[EMAIL PROTECTED]>: To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar the network and X to work, with 6.0 I can get the network to work also. However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people already have. Perhaps NVIDIA think FreeBSD is just a hobby OS.. Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. Like what what are these features? and if they are really important why aren't they on the cards to be included into FreeBSD.. There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current- [EMAIL PROTECTED]" I guess these feature are provided in FreeBSD x86, as a NVIDIA graphics driver is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem different to FreeBSD x86. Is the VM subsystem that low-level? (Pardon my ignorance, have quite got around to reading the FreeBSD kernel book the publisher comped me yet) Actually I think that the feature we are talking about (PAT) is relevant to both amd64 and i386. Proper support for PAT is required for decent PCI Express performance, as I understand it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Valgrind for FreeBSD
On Fri, 2004-04-23 at 16:13, David O'Brien wrote: > On Fri, Apr 23, 2004 at 05:00:30PM +0200, Simon Barner wrote: > > After consultation with Doug Rabson, I have created ports for valgrind > > (stable version and a more ``bleeding edge'' development version). > > > > Until they hit the tree (probably after the ports freeze), you can get them > > at: > > > > http://home.leo.org/~barner/freebsd/valgrind/ > > Please rename "valgrind-devel-port" to "valgrind-snapshot-port". I think I suggested the name valgrind-devel but I have no idea what the latest port naming conventions are. If valgrind-snapshot is more consistent, then thats the name it should have. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pnpparse.c
On Sat, 1 Apr 2000, kibbet wrote: > Hi Doug, > > On 31-Mar-00 Doug Rabson wrote: > > On Sat, 1 Apr 2000, kibbet wrote: > > > >> Hi all, > >> > >> The sys/isa/pnpparse.c MFC today seems to have broken things > >> here with my AWE64, things were happy before the MFC, apart > >> from an odd message during boot > > > > Sorry about that. Can you try with the latest pnpparse.c. > > > > hehe, no probs, its all in the name of advancement :) > > So now I get; > > isa0: too many dependant configs (8) > isa0: unexpected small tag 14 > > > Which dosen't bother me - it dosen't panic and I get sound, yay > Ok, I have another report of this and I think I know the right fix. > > Now I just gotta fix XFree 4 and shmat()... what fun :) :-) -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: agp and 3dfx
On Wed, 26 Jul 2000, Mike Muir wrote: > [EMAIL PROTECTED] wrote: > > > > Hello, > > > > We will need more than the basic X-server to use any new graphics board, as > > their main selling point is 3D, and the basic drivers of X are way behind. > > > > The main issue is in establishing FreeBSD as a "credible" platform > > (how many users of FreeBSD want to pay for a 3D-optimized A|W application ?) > > Quite the opposite -- it won't be users of FreeBSD who will be buying a > $50,000+ software package -- It is those Animators whom should choose to > use FreeBSD! I'm planning to run the Linux version of Maya on FreeBSD as soon as I can get a copy. It isn't that expensive any more - the PC version is about $10,000-$12,000 per seat but its probably the best modelling package for soft skinned characters around. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
