Date: Thu, 7 May 1998 00:22:57 -0700 (PDT) From: Tom <tom@sdf.com> To: Terry Lambert <tlambert@primenet.com> Cc: beng@lcs.mit.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <Pine.BSF.3.95q.980507000533.28352B-100000@misery.sdf.com> In-Reply-To: <199805070244.TAA20312@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 May 1998, Terry Lambert wrote: > > Question: why does it segfault several seconds after producing the > > "abort?" prompt? > > Because it is busy dumping core because of the explicit call to "abort" > because you did not set "yflag" using the "-y" command line option. > > > It had already detected the "hole in map" problem? > > Yes. It won't call panic (a function in utilities.c) if it hasn't > panic'ed. That is bizare. So it prints a "y/n" prompt and calls the panic function anyhow? > The reason it takes so long is that it has a very large data area. Nope. It takes so long since dump is still reading data from the tape at this point. When using "restore -t" on a disk file, it segfaults immediately after printing the prompt. I don't know why restore would have a large data area, because it hasn't done anything at this point. In fact restore dies within 0.20 seconds when accessing a disk file. > One possible reason for this problem *could* ge your limits on the > account doing the restore (see login.conf). I run restore as root. > > Regardless this is still a bug, even assuming that the media is bad (it > > isn't, as I did a full backup and restore to the media with tar). > > Tar proves nothing. See other post. Media is good. Dump to disk file does same thing. I've proved that the tape media and tape drive are not a factor. > That isn't the only thing. Read my other post. I identified by line > item at least 13 things that could give the same symptoms, and a > 14th in the text. Only two of these things are "dump" or "restore", Except that most of those items you listed are the same thing. I've eliminated the tape drive, the tape media, the tape SCSI controller, the cable etc., leaving only three things: - raw access to a partition on EIDE - EIDE controller - dump/restore #2 is doubtful, as it would corrupting data all the time, and fsck never reports a problem, unless the controller has an interesting fail-when-accessed-by-dump bug. Plus it would be like be corrupting files on the filesystem. That isn't happening, as BRU is used to write the bulk of the data onto this filesystem, and it does a verify of its data (mainly because BRU is designed to write to unreliable tape). In fact, I'm crossing #2 off completely. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980507000533.28352B-100000>