Re: Panic with fairly up to date -current, seems NFS related
[EMAIL PROTECTED] wrote: > > Bosko Milekic <[EMAIL PROTECTED]> writes: > > I'm more concerned with whether it's actually normal for the process > > pointer to be NULL in the first place. Is this the case? > > One example (which I don't know if that what's happening here) is when > following symbolic links. namei() calls VOP_READLINK with proc == NULL. What a coincidence, there is a symbolic link involved here. I have a workstation, and a gateway/fileserver machine. I export /usr on the fileserver (slave) and use amd to mount individual directories under /usr in /mnt/slave/ on the workstation. Scattered throughout the workstation are symbolic links to /mnt/slave/foo, which kick amd in gear, and make those directories available where I want them. I realize that this is not an ideal situation, but it's also very common, so if someone is going to find a bug this way, it might as well be me. :) Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with fairly up to date -current, seems NFS related
Bosko Milekic <[EMAIL PROTECTED]> writes: > I'm more concerned with whether it's actually normal for the process > pointer to be NULL in the first place. Is this the case? One example (which I don't know if that what's happening here) is when following symbolic links. namei() calls VOP_READLINK with proc == NULL. > And if so, why is nfs_msg() being called with this pointer being > passed in in the first place? Because the code doesn't check? I thought it was easier to have the check in nfs_msg, but it's only called in two places so doing the check there should also work. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with fairly up to date -current, seems NFS related
On 18 Dec 2000 [EMAIL PROTECTED] wrote: > Since proc can be NULL and most of the other code in nfs_socket > handles it I do think this actually is the right thing to do. > Comments? I'm more concerned with whether it's actually normal for the process pointer to be NULL in the first place. Is this the case? And if so, why is nfs_msg() being called with this pointer being passed in in the first place? > /assar > [...] Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with fairly up to date -current, seems NFS related
John Baldwin <[EMAIL PROTECTED]> writes:
> Grog had a similar panic on IRC the other day:
>
> >#7 0xc021c857 in nfs_msg (p=0x0, server=0xc0bf0cf2 "slave:/usr/home",
> > msg=0xc02ba748 "not responding") at
>
> The 'p' parameter is a process that is supposed to be making the request, and
> thus is going to receive a console message to its tty about the server going
> away. Note that 'p' is NULL. This leads to a NULL dereference in tprintf().
> The 'p' comes from some type of NFS request structure. That is as far as I
> could take it however..
Since proc can be NULL and most of the other code in nfs_socket
handles it I do think this actually is the right thing to do.
Comments?
/assar
Index: nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_socket.c,v
retrieving revision 1.62
diff -u -w -u -w -r1.62 nfs_socket.c
--- nfs_socket.c2000/11/26 20:35:21 1.62
+++ nfs_socket.c2000/12/18 01:58:46
@@ -1969,6 +1969,7 @@
char *server, *msg;
{
+ if (p != NULL)
tprintf(p, LOG_INFO, "nfs server %s: %s\n", server, msg);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Panic with fairly up to date -current, seems NFS related
On 18-Dec-00 Doug Barton wrote: > I built -current world and kernel around 3am PST sunday morning with up > to date sources. Later that same day I added Poul-Henning's console > logging patch. Just a few minutes ago I had a lockup and panic that > thankfully produced a kernel core to work with. It looks like this is > not related to phk's patch, but rather to an NFS issue that I've seen > before. I was copying a 23M file over NFS (mounted via amd) when this > lockup and panic happened. > > My workstation is the NFS client, running -current. The NFS server is > running FreeBSD 3.5.1-STABLE-1014 #0: Mon Oct 16 00:00:13 PDT 2000. If > anyone wants me to do more debugging with this, let me know. I'm going > out in a bit, but I will likely be available later tonight or tomorrow. > > Doug Grog had a similar panic on IRC the other day: >#7 0xc021c857 in nfs_msg (p=0x0, server=0xc0bf0cf2 "slave:/usr/home", > msg=0xc02ba748 "not responding") at The 'p' parameter is a process that is supposed to be making the request, and thus is going to receive a console message to its tty about the server going away. Note that 'p' is NULL. This leads to a NULL dereference in tprintf(). The 'p' comes from some type of NFS request structure. That is as far as I could take it however.. > /usr/src/sys/nfs/nfs_socket.c:1972 >#8 0xc021b742 in nfs_timer (arg=0x0) at > /usr/src/sys/nfs/nfs_socket.c:1424 >#9 0xc01956d8 in softclock (dummy=0x0) at > /usr/src/sys/kern/kern_timeout.c:141 >#10 0xc01834f4 in sithd_loop (dummy=0x0) at > /usr/src/sys/kern/kern_intr.c:227 -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
