Removal of Giant from the VFS layer for 10.0
[ Sorry for cross-posting, but I included -arch@ for technical discussion, -current@ for reaching the wider audience and -fs@ for the relevance of the matter.] During the last years a lot of effort by several developers happened in order to reduce Giant influence over the entire kernel. The VFS layer didn't make an exception, as many several tasks have been completed along the years, including fine-grained locking for vnodes lifecycle, fine-grained locking of the VFS structure (mount), fine-grained locking of specific filesystems (UFS, NFS, etc.) and several locking improvements to surrounding subsystem (buffer cache, filedesc objects, VM layer, etc.). While FreeBSD did pretty well so far, a major push is still needed in order to completely remove Giant from our VFS and buffer cache subsystems. At the present time, the biggest problem is that there are still filesystems which are not properly fine-grained locked, relying on Giant for assuring atomicity. It is time to make an decision for them, in order to aim for a Giant-less VFS in our next release. With the aid of kib and rwatson I made a roughly outlined plan about what is left to do in order to have all the filesystems locked (or eventually dropped) before 10.0) and is summarized here: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS As you can note from the page, the plan is thought to be 18 months long, including time for developers to convert all our filesystems and let thirdy-party producers do the same with their proprietary filesystems. Also the introduction (and later on removal) of VFS_GIANT_COMPATIBILITY is thought to stress-out the presence of not-yet MPSAFE filesystems used by consumers and force a proactive action. As you can note from the page, the list of filesystems to be converted is small and well contained, but there are some edge cases that really concerns me, like ntfs and smbfs. I took over leadership of ntfs, but if someone is willing to override myself, please just drop an e-mail and I'll happilly hand over someone else. About smbfs, I really think this is really the key filesystem we should fix in the list and it is time for someone to step up and do the job (including also locking and reworking netsmb). I knew there was a Google SoC going on this topic, but didn't have further updates to the matter in weeks. Ideally, after all the filesystems are locked, what should happen is to remove all Giant reference from the VFS, as kib's patch present in the wiki page. If some filesystem is still left for the 1st Semptember of next year, it is going to be disconnected from the tree along with Giant axing. As the locking of filesystems progresses, we can create subsections for each filesystems including technical notes on the matter. So fare there is none because the effort is still not started. The page is also thought to contain technical notes on how to operate the locking of filesystems, in more general way. I added the msdosfs example as a reference but other cases may have different problems. However, as the state of all the filesystems listed in the black page is a bit unknown, I'd suggest you to first make it work stable and just in the end work on locking. Also, please remind that locking doesn't need to be perfect at the first time, it is enough to bring the filesystem out of the Giant influence intially. Of course, for key filesystems (smbfs in primis) I'd expect to have full fine-grained locking support at some point. During the 18 months timeframe I'll send some reminder and status updates to these lists (monthly or bi-monthly). If there is anything else you want to discuss about this plan, don't hesitate to contact me. There is one last thing I want to stress out: this type of activities rely a lot on the audience to step up and make the job. Please don't expect someone else to fix the filesystem for you, but be proactive as much as you can, offering quality time for development, testing and reviews. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Console problem with ALT-F# keys
Hi, On Friday 26 August 2011 07:56:04 Pegasus Mc Cleaft wrote: I have recently installed this into a new machine and had chance to did you solve your problem? I have had a similar problem yesterday after upgrading my ports via packages. I could not even switch to the consoles anymore. This was solved after I compiled X and the drivers from the ports and installed them. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS mountd version 3 over TCP
Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/11 22:16, Steve Wills wrote:
On 08/26/11 21:41, Steve Wills wrote:
Hi,
I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi
4.1.0.
When I attempt the mount, it logs this message:
The NFS server does not support MOUNT version 3 over TCP
Have I configured something wrong and if so what? Or is this
something
related to the new NFS code?
I guess a little more info would be helpful...
rc.conf has:
nfs_server_enable=YES
rpcbind_enable=YES
mountd_enable=YES
rpc_statd_enable=YES
rpc_lockd_enable=YES
/etc/exports contains, amongst others:
/boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask
255.255.255.0
rpcinfo shows:
program version netid address service owner
10 4 tcp 0.0.0.0.0.111 rpcbind superuser
10 3 tcp 0.0.0.0.0.111 rpcbind superuser
10 2 tcp 0.0.0.0.0.111 rpcbind superuser
10 4 udp 0.0.0.0.0.111 rpcbind superuser
10 3 udp 0.0.0.0.0.111 rpcbind superuser
10 2 udp 0.0.0.0.0.111 rpcbind superuser
10 4 tcp6 ::.0.111 rpcbind superuser
10 3 tcp6 ::.0.111 rpcbind superuser
10 4 udp6 ::.0.111 rpcbind superuser
10 3 udp6 ::.0.111 rpcbind superuser
10 4 local /var/run/rpcbind.sock rpcbind superuser
10 3 local /var/run/rpcbind.sock rpcbind superuser
10 2 local /var/run/rpcbind.sock rpcbind superuser
15 1 udp6 ::.2.224 mountd superuser
15 3 udp6 ::.2.224 mountd superuser
15 1 tcp6 ::.2.224 mountd superuser
15 3 tcp6 ::.2.224 mountd superuser
15 1 udp 0.0.0.0.2.224 mountd superuser
15 3 udp 0.0.0.0.2.224 mountd superuser
15 1 tcp 0.0.0.0.2.224 mountd superuser
15 3 tcp 0.0.0.0.2.224 mountd superuser
This line indicates that mountd over tcp is registered for v3,
so I suspect the error message is misleading??
As you might guess, this rpcinfo output indicates nfsd wasn't running.
I
am seeing this:
can't bind udp addr *: Address already in use
Hmm, this should only happen if the nfsd is already running (or was
recently running), since nothing else binds to port #2049 normally.
(If something else grabbed port#2049 for udp, then that would explain
this.) I assume the message was from nfsd?
in syslog. Setting this:
nfs_server_flags=-t -n 4
allowed it to startup, but it then timed out an fsinfo call. Adding -o
to the nfs_server_flags to use the old nfs server allowed vmware to
mount. FWIW, I can't find any reason for the udp message above,
nothing
seems to be using it that I can find. Ideas? tcpdumps are available if
anyone want them.
Could you make sure you have this patch, which was committed by zkirsch
as r224637. It was a fix they needed for a customer having difficulties
mounting via VMware. (Our discussion about it agreed that the VMware
client was broken for this case, but the patch fixed the problem.)
If you didn't already have this patch, please test it (ie. apply it and
take -o off the nfsd flags) and let us know if it fixed your problem?
--- head/sys/fs/nfsserver/nfs_nfsdserv.c2011/07/31 20:06:11 224554
+++ head/sys/fs/nfsserver/nfs_nfsdserv.c2011/08/03 18:50:19 224637
@@ -620,7 +620,7 @@
vnode_t vp, NFSPROC_T *p, struct nfsexstuff *exp)
{
u_int32_t *tl;
- int error = 0, cnt, len, getret = 1, reqlen, eof = 0;
+ int error = 0, cnt, getret = 1, reqlen, eof = 0;
mbuf_t m2, m3;
struct nfsvattr nva;
off_t off = 0x0;
@@ -714,11 +714,11 @@
eof = 1;
} else if (reqlen == 0)
cnt = 0;
- else if ((off + reqlen) nva.na_size)
+ else if ((off + reqlen) = nva.na_size) {
cnt = nva.na_size - off;
- else
+ eof = 1;
+ } else
cnt = reqlen;
- len = NFSM_RNDUP(cnt);
m3 = NULL;
if (cnt 0) {
nd-nd_repstat = nfsvno_read(vp, off, cnt, nd-nd_cred, p,
@@ -748,7 +748,7 @@
*tl++ = txdr_unsigned(cnt);
} else
NFSM_BUILD(tl, u_int32_t *, 2 * NFSX_UNSIGNED);
- if (len reqlen || eof)
+ if (eof)
*tl++ = newnfs_true;
else
*tl++ = newnfs_false;
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)
iQEcBAEBAgAGBQJOWF6PAAoJEPXPYrMgexuhHPYIAJ6SVxtORDbesvU35ktAS/id
5iWyTWO3CTHXT42uP4IZBT1o2AWFu6e9wUX84YEZyujMln0E++8hZccaa8zQBJhr
febHkZxqPdQOo/mpg1ci5J70Hs1UBV9cxU3uOA83vxunOM6xwA0B+4krfflj/k7P
cPtpztmuepQQ8/S5hB5ajnfM/gFOh1f2uPwWTj2/5NSWMoVfN3f0539bh05XKfRa
4X7XKxN/J4HBRGaNjnL8IWu86AW60H9Q3gdisdtT0k9sK4X3DswmiRMlMt4M4rS8
oX0vrgruTiKZf+bsraYvhuo4JyselXMicTnW7rUOVx8jiNVVk1nymSVF1XDUOrw=
=MeJv
-END PGP SIGNATURE-
Re: NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/11 09:00, Rick Macklem wrote: This line indicates that mountd over tcp is registered for v3, so I suspect the error message is misleading?? Forgot to reply to this part, and I should have been more clear earlier. When I used the default nfsd flags, it failed to startup, or exited immediately on startup (not sure which). When I removed -u flag, it started up and that message was replaced with the one about fsinfo timeout. I can get the exact error message and tcpdump if you like. I then added -o flag to nfsd (didn't put -u back) and then things seemed to work OK. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWPPUAAoJEPXPYrMgexuhrLIH/jpRbAaKde9qi3xzsiIaZsuI +O31ScAk+weud90cEjf/N9PwW5PfSJYHMO03hliMVGuOphkwYnpN2AStExzScfmm nCFLz5UpzeKjznzirSOSNCGqwAyN3aPrghlyqNNi5eSkM9s0BdJgKBd+H9oSk7JE 7rf83Q2kPdqfvwhvRNpImC5oEXkZpExmitoIhESdnI/asr5OBwHIh8HthgIgMx+o 0t7v+togz0dT2jR7D+U1QbKhH5QP8pamjpP80D4TsO8P9pGt/PUuSBQAwDfQ3pjf Tjnc2t9YMQ+hw3zqYTRrNCNMvaH7PlyAW0LvuW1Nhk8mus6HFxP1St/hgko+Y+8= =Pdq4 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Removal of Giant from the VFS layer for 10.0
On Sat, Aug 27, 2011 at 02:00:50PM +0200, Attilio Rao wrote: [ Sorry for cross-posting, but I included -arch@ for technical discussion, -current@ for reaching the wider audience and -fs@ for the relevance of the matter.] During the last years a lot of effort by several developers happened in order to reduce Giant influence over the entire kernel. The VFS layer didn't make an exception, as many several tasks have been completed along the years, including fine-grained locking for vnodes lifecycle, fine-grained locking of the VFS structure (mount), fine-grained locking of specific filesystems (UFS, NFS, etc.) and several locking improvements to surrounding subsystem (buffer cache, filedesc objects, VM layer, etc.). While FreeBSD did pretty well so far, a major push is still needed in order to completely remove Giant from our VFS and buffer cache subsystems. At the present time, the biggest problem is that there are still filesystems which are not properly fine-grained locked, relying on Giant for assuring atomicity. It is time to make an decision for them, in order to aim for a Giant-less VFS in our next release. The scope of the project should be made slightly more concrete. If you do not use a non-mpsafe fs, then VFS does not acquire Giant. This is true at least for stable/8 and HEAD kernels, might be also true for stable/7, but I do not remember for sure. The aim of the project is to remove compatibility shims that conditionally acquire Giant on the as-needed basis to allow non-mpsafe filesystems to operate still under the usual locking regime. In other words, the project will not make anything much faster or scalable, but to remove some quite large amount of the crafty code from our VFS, which is, unfortunately, not known for the very clean interfaces. pgpspuQc7Chwd.pgp Description: PGP signature
Re: buildworld failure r223619 to 225128
On 8/25/11, Dimitry Andric d...@freebsd.org wrote: On 2011-08-25 17:12, Beach Geek wrote: make buildworld failed trying to upgrade from r223619 to r225128. (Note: Updating other boxes from r224774 to r225119 went flawless) On failing laptop (Toshibs Sat C655D) /usr/include/c++/4.2/bits/stringfwd.h:56: internal compiler error: Segmentation fault: 11 Please submit full report, That is most likely a hardware problem. Please run a full memtest, and/or any other hardware diagnostics you can find. It could also be running out of memory, but that is less likely, and you usually get another signal then. But who knows what might happen if you choke a compiler. :) I do rm -r /usr/obj/* and make clean (in /usr/src) before doing buildworld on all boxes. I also tried compiling new GENERIC kernel then doing buildworld. It failed with same message. It dies on exactly the same file? Reverted to old/original kernel and tried make depend in /usr/src. You can't do that, you must run buildworld. It failed with... (by hand again) === lib/clang/libllvmarmasmparser (depend) tblgen -l /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target -gen-asm-matcher -o ARMGenAsm Matcher.inc.h /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM/ARM.td tblgen: Record 'CCR', field 'MemberList' does not have a list initializer! *** Error code 1 Stop in /usr/src/lib/clang/libllvmarmasmparser. Yes, this is expected. When you do not use the buildworld target, the tblgen used above will be run from /usr/bin, which is too old. This is why buildworld first builds an up-to-date tblgen under /usr/obj, and uses that to generate the needed files. This laptop also runs MS Win 7/64 and FreeBSD 9 amd. The FBSD amd upgraded ok. The buildworld always fails in same place, with same message (5 tries). I'm running diags on it right now just to make sure the hardware's good. The reason I tried make depend was because of a reference to r221543 that said it required make depend before buildworld. (a shot in the dark before posting to mail list). I will post if I find any hardware problems. Thanks, Beach Geek PS. Option on updating to a version inbetween, then to latest??? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible mountroot regression
On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote:
It seems that after the introduction of the mountroot scripting language a
user
now has exactly one chance to try to specify a correct root device at the
mountroot prompt. I am not sure that that is convenient/enough.
This is no different from before.
I suspect that the following code is the cause:
static void
vfs_mountroot_conf0(struct sbuf *sb)
{
char *s, *tok, *mnt, *opt;
int error;
sbuf_printf(sb, .onfail panic\n);
…
Yes.
It is certainly a behavior we can improve upon. It's
rather annoying to get a panic on a typo. However,
we must remain cognizant of the fact that an immediate
hard failure is what's needed at times.
Maybe a good approach is to change to .onfail retry
and extend the root mount prompt with a reboot command,
so that the user/operator is does not have to worry
about typos *and* don't have to trigger a panic just
so that he/she can initiate a reboot.
Thoughts?
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Areca 1280ML ccb command time out
Hi, after upgrading vom FBSD8.2 to todays current, I have the problem that my two Areca controllers don't find any disks. In dmesg there are a lot of messages like: arcmsr0: scsi id 2 lun 0 cmd=0x12 srb='0xff83e298f000' ccb command time out! The whole dmesg can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt I found no similar problems on the list. So anybody have an idea where to start with this problem? Best regards, Uwe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
http://www.freebsd.org/marketing/os-comparison.html
This website should be brushed up or taken offline! It seems full of vintage stuff from glory days. http://www.freebsd.org/marketing/os-comparison.html O. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
On Sat, Aug 27, 2011 at 12:13 PM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: This website should be brushed up or taken offline! It seems full of vintage stuff from glory days. http://www.freebsd.org/marketing/os-comparison.html Agreed. Things have changed quite a bit in the last decade. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS mountd version 3 over TCP
Steve Wills wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/11 09:00, Rick Macklem wrote: This line indicates that mountd over tcp is registered for v3, so I suspect the error message is misleading?? Forgot to reply to this part, and I should have been more clear earlier. When I used the default nfsd flags, it failed to startup, or exited immediately on startup (not sure which). I have no idea w.r.t. this one. The failure is the bind(2) syscall failing for port #2049 over UDP, but I have no idea why? (Others aren't seeing this, as far as I know.) When I removed -u flag, it started up and that message was replaced with the one about fsinfo timeout. I can get the exact error message and tcpdump if you like. Both the message and a tcpdump (binary capture of traffic between the two hosts) would be useful. A tcpdump command like this done on the FreeBSD server: tcpdump -s 0 -w file host client You can just email me file as an attachment and I'll take a look at it. I then added -o flag to nfsd (didn't put -u back) and then things seemed to work OK. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWPPUAAoJEPXPYrMgexuhrLIH/jpRbAaKde9qi3xzsiIaZsuI +O31ScAk+weud90cEjf/N9PwW5PfSJYHMO03hliMVGuOphkwYnpN2AStExzScfmm nCFLz5UpzeKjznzirSOSNCGqwAyN3aPrghlyqNNi5eSkM9s0BdJgKBd+H9oSk7JE 7rf83Q2kPdqfvwhvRNpImC5oEXkZpExmitoIhESdnI/asr5OBwHIh8HthgIgMx+o 0t7v+togz0dT2jR7D+U1QbKhH5QP8pamjpP80D4TsO8P9pGt/PUuSBQAwDfQ3pjf Tjnc2t9YMQ+hw3zqYTRrNCNMvaH7PlyAW0LvuW1Nhk8mus6HFxP1St/hgko+Y+8= =Pdq4 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS mountd version 3 over TCP
Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/11 22:16, Steve Wills wrote:
On 08/26/11 21:41, Steve Wills wrote:
Hi,
I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi
4.1.0.
When I attempt the mount, it logs this message:
The NFS server does not support MOUNT version 3 over TCP
Have I configured something wrong and if so what? Or is this
something
related to the new NFS code?
I guess a little more info would be helpful...
rc.conf has:
nfs_server_enable=YES
rpcbind_enable=YES
mountd_enable=YES
rpc_statd_enable=YES
rpc_lockd_enable=YES
/etc/exports contains, amongst others:
/boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask
255.255.255.0
rpcinfo shows:
program version netid address service owner
10 4 tcp 0.0.0.0.0.111 rpcbind superuser
10 3 tcp 0.0.0.0.0.111 rpcbind superuser
10 2 tcp 0.0.0.0.0.111 rpcbind superuser
10 4 udp 0.0.0.0.0.111 rpcbind superuser
10 3 udp 0.0.0.0.0.111 rpcbind superuser
10 2 udp 0.0.0.0.0.111 rpcbind superuser
10 4 tcp6 ::.0.111 rpcbind superuser
10 3 tcp6 ::.0.111 rpcbind superuser
10 4 udp6 ::.0.111 rpcbind superuser
10 3 udp6 ::.0.111 rpcbind superuser
10 4 local /var/run/rpcbind.sock rpcbind superuser
10 3 local /var/run/rpcbind.sock rpcbind superuser
10 2 local /var/run/rpcbind.sock rpcbind superuser
15 1 udp6 ::.2.224 mountd superuser
15 3 udp6 ::.2.224 mountd superuser
15 1 tcp6 ::.2.224 mountd superuser
15 3 tcp6 ::.2.224 mountd superuser
15 1 udp 0.0.0.0.2.224 mountd superuser
15 3 udp 0.0.0.0.2.224 mountd superuser
15 1 tcp 0.0.0.0.2.224 mountd superuser
15 3 tcp 0.0.0.0.2.224 mountd superuser
As you might guess, this rpcinfo output indicates nfsd wasn't running.
I
am seeing this:
can't bind udp addr *: Address already in use
in syslog. Setting this:
nfs_server_flags=-t -n 4
I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a
second time for UDP, but someone on the net side might know? (Just in
case it is a problem that has already been fixed, I'd try a newer kernel.)
allowed it to startup, but it then timed out an fsinfo call. Adding -o
to the nfs_server_flags to use the old nfs server allowed vmware to
mount. FWIW, I can't find any reason for the udp message above,
nothing
seems to be using it that I can find. Ideas? tcpdumps are available if
anyone want them.
The new server was broken by r224778 on Aug. 11 and fixed by r224911 on
Aug. 16. (I recall you mentioning Aug. 11?)
Here's the r224911 patch:
--- head/sys/fs/nfsserver/nfs_nfsdport.c2011/08/11 12:30:23 224778
+++ head/sys/fs/nfsserver/nfs_nfsdport.c2011/08/16 14:23:16 224911
@@ -3036,7 +3036,6 @@
*/
if ((error = fget(td, sockarg.sock, CAP_SOCK_ALL, fp)) != 0)
goto out;
- return (error);
if (fp-f_type != DTYPE_SOCKET) {
fdrop(fp, td);
error = EPERM;
I suspect this is what caused the fsinfo RPC to not reply.
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)
iQEcBAEBAgAGBQJOWF6PAAoJEPXPYrMgexuhHPYIAJ6SVxtORDbesvU35ktAS/id
5iWyTWO3CTHXT42uP4IZBT1o2AWFu6e9wUX84YEZyujMln0E++8hZccaa8zQBJhr
febHkZxqPdQOo/mpg1ci5J70Hs1UBV9cxU3uOA83vxunOM6xwA0B+4krfflj/k7P
cPtpztmuepQQ8/S5hB5ajnfM/gFOh1f2uPwWTj2/5NSWMoVfN3f0539bh05XKfRa
4X7XKxN/J4HBRGaNjnL8IWu86AW60H9Q3gdisdtT0k9sK4X3DswmiRMlMt4M4rS8
oX0vrgruTiKZf+bsraYvhuo4JyselXMicTnW7rUOVx8jiNVVk1nymSVF1XDUOrw=
=MeJv
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/11 20:55, Rick Macklem wrote: I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a second time for UDP, but someone on the net side might know? (Just in case it is a problem that has already been fixed, I'd try a newer kernel.) Will do, see below. The new server was broken by r224778 on Aug. 11 and fixed by r224911 on Aug. 16. (I recall you mentioning Aug. 11?) My kernel is from Aug 13, so definitely would fall into that range. I'll update and rebuild and see how it goes. Thanks! Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWZinAAoJEPXPYrMgexuhgp0H/1Dl9Bica8wbx5wLkkaPg5KM Rf53qdAgi/TarcMxufN+ujqx1EBu02hsSfB0vx8B0EZ9Ta1qWA/b2aL8SHJsXZFB gWPyr6sLINLcoaKGJ6Esp4QcIaU0PHOn4OhSGSMaZKYuMlXGsqJyJ3Wn6D46/4Re CbxioTfNT3c85x/khSE3nOCKsxKddKmM+VtuOloNRji969QlYH/1ZWItxbg6Tr1m hkT6v6hAM+EnvuLxlOJMTIegeec+WilIYSyP/FcuB2fcov1rdJSOOqOAUBHiBkRc uz3ADLr1QhwVue7sSA2PNDo3jQhtA7HFQKrEnIAW1xQFKuuapdgxr/wSDu2+T30= =5j1q -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Console problem with ALT-F# keys
On Saturday 27 August 2011 13:11:43 Erich Dollansky wrote: Hi, On Friday 26 August 2011 07:56:04 Pegasus Mc Cleaft wrote: I have recently installed this into a new machine and had chance to did you solve your problem? I have had a similar problem yesterday after upgrading my ports via packages. I could not even switch to the consoles anymore. Hi Erich, No, I havent.. But I am leaning towards a hardware quirk at this point. Since the original post, I have done a bit more digging and had a chance to test against another machine and it does not have the same problem. I also found out that even though I had connected a PS2 keyboard to the motherboards PS2 ports, these are not conventional ports. They look like they are actually connected to a converter that sits on the motherboards USB controller. On the second test machine, I attached a PS2 keyboard to the PS2 Port and a USB keyboard (Sun type 6) to the USB ports. Neither of the keyboards have this problem.. With this in mind, I am fairly sure its not a BSD issue and suspect its whatever converter they put on this Intel motherboard. Weird... Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
