Date: Mon, 28 Apr 1997 08:44:34 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: freebsd-hackers@freebsd.org Subject: Re: A Desparate Plea for Help... Message-ID: <XFMail.970428184022.Shimon@i-Connect.Net> In-Reply-To: <199704280221.LAA13874@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Michael Smith; On 28-Apr-97 you wrote: ... > Simon; I have heard this reported before, but I have a Jaz, and > regularly access it when it's not spinning. I have _never_ had a > problem with this, and if you can provide something that can be > reproduced elsewhere, then I am certain that it will be fixed. AT TIMES, we get this problem where the Jaz does not reply quickly enough. If we are lucky, we are at the console and can just ``continue'' in the debugger. It is a very minor problem at this time (priority-wise) ... > That's not what that response means. "I can't make it happen here" > means "I can't work out what is wrong because I can't reproduce the > problem, and I need to reproduce the problem to have all the > information I need to hand". I understand that that what the response should be :-) Sometimes one gets more acusatory notes as in ``why are you saying that my favorite O/S has a bug?''. Being very tired and the only response having been such, I made a comment that may have better been kept quiet. > If you can configure your system(s) to dump kernel cores, and put the > cores and and matching kernels _compiled_with_debugging_information_ > up for FTP, this is _very_ helpful. If you can give details so that > we can check out exactly the same sources as you are using, that'll > help too. I will do that immediately! The system in question is sendero.i-connect.net (206.190.143.100). Anonymous FTP works. The system is normally on a modem connection but will be on ISDN BONDING for the next few days. The kernel dump will be in the top directory. The source tree is RELENG_2_2, last cvsupped and cvs updated and make world'ed on 24-Apr-97 at 1536. ... > The trap you see above is somewhere near the top of spec_open in > sys/miscfs/specfs.c. Without knowing exactly what the trap was; > specifically the fault address, it's hard to infer more. There are > several pointer references near the top of spec_open that might be > the problem, the most likely IMHO is : > > /* > * Don't allow open if fs is mounted -nodev. > */ > if (vp->v_mount && (vp->v_mount->mnt_flag & MNT_NODEV)) > return (ENXIO); I have surrounded this code with printf's. Quite few of them. The result was a crash with trap 9 in generic_bzero + 0x0f. This was preceeded with several calls to _end. At _generic_bezero + 0x0f, the offending instruction was rtosl %es:(%edi) - whatever that means (am too old to remember x86 assembly :-) > We have seen problems with vp->v_mount being NULL before; this > appears most often with MFS filesystems. Are you using MFS in your > systems? Nope. Thanx so much for your help. I will go now and crash the system. Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970428184022.Shimon>