Re: RE: Strange rpc.statd and mount_nfs
On 11-Jun-00 Matthew Dillon wrote:
:Here is a rather suspicious fix, I have not looked at rpc call
:use in detail:
:
:--- mount_nfs.c.origSat Jun 10 11:08:19 2000
:+++ mount_nfs.c Sat Jun 10 11:09:06 2000
:@@ -784,10 +784,11 @@
:warnx("%s", clnt_sperror(clp,
:"bad MNT RPC"));
:} else {
:- auth_destroy(clp-cl_auth);
:- clnt_destroy(clp);
:retrycnt = 0;
:}
:+ auth_destroy(clp-cl_auth);
:+ clnt_destroy(clp);
:+ so = RPC_ANYSOCK;
Good catch! This patch looks good to me, I am going to go ahead
and commit it.
Resetting 'so' is good code form, but I went through the rpc code
and it wasn't an operational bug ... the rpc code can overwrite so
in the case of a failure but only with '-1', which is RPC_ANYSOCK
anyway. Still, it's good not to make assumptions.
-Matt
Without the "so = RPC_ANYSOCK" and no other changes, the "weak credential"
failure turned into a "bad file descriptor" failure, so I think the non -1
socket fd is being reused. Perhaps the initialization of "so" should be moved
into the retry loop.
Jonathan Hanna [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Strange rpc.statd and mount_nfs
As was pointed out, rcp.statd is supposed to have a large VSZ, but
mount_nfs should not and my swap was getting used up.
mount_nfs will do an RPC clntudp_create for every attempt, but
only a clnt_destroy after a success.
Here is a rather suspicious fix, I have not looked at rpc call
use in detail:
--- mount_nfs.c.origSat Jun 10 11:08:19 2000
+++ mount_nfs.c Sat Jun 10 11:09:06 2000
@@ -784,10 +784,11 @@
warnx("%s", clnt_sperror(clp,
"bad MNT RPC"));
} else {
- auth_destroy(clp-cl_auth);
- clnt_destroy(clp);
retrycnt = 0;
}
+ auth_destroy(clp-cl_auth);
+ clnt_destroy(clp);
+ so = RPC_ANYSOCK;
}
}
if (--retrycnt 0) {
On 08-Jun-00 Jonathan Hanna wrote:
I am running a fairly recent current and noticed my swap seemed
a little overused.
bash-2.02$ uname -a
FreeBSD roller.pangolin-systems.com 5.0-CURRENT FreeBSD 5.0-CURRENT #41: Sun May 14
11:50:20 PDT 2000 [EMAIL PROTECTED]
sy
stems.com:/home/src/sys/compile/ROLLER i386
bash-2.02$ uptime
11:27PM up 3 days, 5:15, 7 users, load averages: 0.21, 0.17, 0.14
ps shows:
...
0 212 1 29 2 0 2630360 select IWs ??0:00.00 rpc.stat
This is expected.
This looks big.
0 1382 1 0 2 0 3716 352 select I ??0:01.02 xterm -geometry
80x25 -fg springgree
...
1000 1504 1 0 10 0 86368 408 nanslp Is??0:07.93 nfs -o bg -o
noauto ghost-p1:/home/j
This seems rather large as well.
Not expected.
...
I do remember an nfs mount failing and perhaps being backgrounded.
This was it, in normal circumstances the problem would not show up.
I guess I shouldn't be leaving failing mounts around!
Jonathan Hanna [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Strange rpc.statd and mount_nfs
-o noauto ghost-p1:/home/j This seems rather large as well. 0 2917 1 0 2 0 3724 632 select S ??0:24.77 xterm -title ghost -geometry 80x25 - 0 4840 1 0 2 0 3716 1052 select I ??0:00.37 xterm -geometry 80x25 -fg springgree 1000 595 594 0 10 0 1280 696 wait Ssp10:00.72 bash 1000 6887 595 1 46 0 460 240 - R+p10:00.00 ps -axl 1000 603 602 0 3 0 12640 ttyin IWs+ p20:00.00 bash 1000 1326 1325 0 10 0 12640 wait IWs p40:00.00 bash 0 1403 1326 0 3 0 10520 ttyin IW+ p40:00.00 _su (csh) 1000 1377 1376 0 10 0 12560 wait IWs p50:00.00 bash 0 1378 1377 0 3 0 10520 ttyin I+p50:00.20 _su (csh) 1000 1383 1382 1 3 0 12560 ttyin IWs+ p60:00.00 bash 0 2918 2917 0 2 0 1264 204 select Ss+ p70:19.39 /usr/local/bin/ssh -l jhanna ghost ( 1000 4841 4840 0 3 0 1260 512 ttyin Is+ p90:00.07 bash 0 412 1 0 3 0 9040 ttyin IWs+ v00:00.00 /usr/libexec/getty Pc ttyv0 0 413 1 0 3 0 9040 ttyin IWs+ v10:00.00 /usr/libexec/getty Pc ttyv1 0 414 1 0 3 0 9040 ttyin IWs+ v20:00.00 /usr/libexec/getty Pc ttyv2 0 375 1 0 2 0 13520 select IW+ con- 0:00.00 /usr/local/sbin/rplayd The 4.0 stable box that nfs may be interating with also has a huge rpc.statd. Should I be worried? I do remember an nfs mount failing and perhaps being backgrounded. Jonathan Hanna [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
On 22-May-00 Kazutaka YOKOTA wrote: Please, if you can avoid it, don't unplug and replug the mouse while the power is on. The PS/2 mouse interface is generally not capable of hot plugging/unplugging. As for sleep/wake-up problem on the laptop computers, you may be able to resolve the problem by adding the following kernel options. options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND Is it possible to do a reset after seeing the "psmintr: out of sync (00c0 != )"? Jonathan Hanna [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Anyone else seeing jumpy mice?
On 22-May-00 Jordan K. Hubbard wrote: No, I don't mean rodents who've nibbled on chocolate-covered expresso beans, I mean PS/2 mice which fall victim to this new problem: May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). I've seen it for the last few weeks and can only think that something must be stomping on the psm driver now (or the driver is missing interrupts for reasons of its own). Anyone else seeing this? Yes, recently on 4.0-stable, though provoked by unplugging and replugging in the mouse. It did not recover. This I thought sounded like a PR on the mouse being dead after a wakeup from sleep mode. Jonathan Hanna [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do not think is always did. I am running 4.0-CURRENT form Feb 19. The trace is: panic lockmgr: locking against self lockmgr mv_map_growstack grow_stack trap_pfault trap calltrap subyte syscall ... A command on a running image such as this usually does it, though I do not know what conditions are neccessary: fincore /usr/local/netscape-4.5/communicator-4.5.bin Jonathan Hanna pango...@home.com fincore.c Description: fincore.c
