Hi!
Trying to kill the keyboard, [EMAIL PROTECTED] produced:
> > You have to start by explaining that you are a masochist and
> > get turned on by being slapped ... :-)
> Whip me, beat me, make me write bad cheques!
And I thought it was:
"Whip me. Beat me. Make me maintain AIX."
:-)
> Unless thier non forign floppies...
Preformatted floppies.
There have been quite a number of cases where even shrinkwrapped
floppies / CDs had viruses. And even more with preformatted ones
(probably because more are sold or the multipying factor is
higher).
> > viruses: No Intel platform. Right?
> nope... Dual P133, remember?
Ah. That's the spoofing :-) (Ok, let's cut the conspiration
theories.)
> > No (I think). Unless ftape senses how much fragmented your disks
> > are (or if you reintarnated your drives) and then randomly hickups
> > (or behaves). As you looked through the code (didn't you?),
> > you may have noticed there's no such routine build in. Or did
> > you recompile ftape in the mean time? Changed the version?
> > And then sudenly it stopped, but on the (current) backup you
> > still had an *age* old version ...
> I think it's irq saturation from the fragmentation... Same thing can happen
> to high speed serial I/O...
Well, that would be more because of irq saturation and unhelpful
priority, I think. I just can't see how the fragmentation ---
once the lib is in memory --- can hurt.
> I think it's more of a latency problem... I know
> it's also probably a bad thing to cli() arround the code, but who knows... I
> might even try that.
Try it out.
> > Maybe your computer *IS* possessed. Or it's a Heisenbug,
> BOO!
Why? Heisenbugs are nothing supernatural. They are a very
sound physical principle ... and they appear from time to time.
> > Naah, I'd rather not look up to anything with m$ in it, it may
> > cost $2000 :-)
> Not even crash.01-01.oo.ms? (I own that too... tee hee)
Why? NT5 has been slightly delayed and is scheduled for the
first Quarter 1901. There should be no more troubles since NT5
is 00.secure, or something, right? :-)
> Ok, I'll try swapout more ram, we'll see what happens...
> Prolly the first logical thing I didn't think of doing.
> Simple fix too. I suppose you suggest I exit X too, so that it frees ram,
> right?
X takes perhaps 5-7 Megs here (+ libs), and is no problem.
But see that noone and nothing is using the box, i.e. no users,
no net, no X, no daemons (other than idling ones or syslog &
co), no nothing. Also *do* use large buffers[1], as that should
help if your data to be backupppe to be backupppedd is slow
(perhaps because of fragmentation). It may or may not help ...
but only trial & error will show.
[1] as in buffer -m 20m -p 80% -u 100 ...
-Wolfgang
--
PGP 2 welcome: Mail me, subject "send PGP-key".
Unsolicited Bulk E-Mails: *You* pay for ads you never wanted.
How to dominate the Internet/WWW/etc? Destroy the protocols! See:
http://www.opensource.org/halloween.html
