*BSD News Article 73127


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.eng.convex.com!newshost.convex.com!newsgate.duke.edu!news.mathworks.com!news.kei.com!news.texas.net!news.sprintlink.net!news-fw-6.sprintlink.net!helena.MT.net!nate
From: nate@trout.mt.sri.com (Nate Williams)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Parallel laplink abuse leads to death of kernel secondary timer
Date: 8 Jul 1996 16:40:50 GMT
Organization: SRI Intl. - Montana Operations
Lines: 52
Message-ID: <4rrdmi$747@helena.MT.net>
References: <4rn4ip$kcr@harbinger.cc.monash.edu.au>
Reply-To: "Nate Williams" <nate@sneezy.sri.com>
NNTP-Posting-Host: trout.mt.sri.com
Keywords: printer port laplink cable timer

In article <4rn4ip$kcr@harbinger.cc.monash.edu.au>,
Mike  Mc Gaughey <mmcg@cs.monash.edu.au> wrote:

[ High interrupt load using the parallel port IP driver wipes out the
  profiling clock on 2.1R ]

>What I want to know is: is this a major problem?

I'd say you have a hardware bug.  I've used parallel IP across two
laptops running an NFS 'make world' (don't try this at home, the int
errupt load was NUTS due to the parallel port not being designed for
this stuff) and didn't have a bit of problems.  I've also used it from a
laptop to a Pentium desktop and regularly connect to my 486/66 at home
as well.

  Is there anything
>else (besides statistics gathering) that relies on this secondary
>clock, which breaks if the clock stops?  Is there a more gentle way of
>restarting the clock (than a reboot)?

You *could* disable it completely.  I've got patches in -current that
disable the rtc which is necessary for some crappy APM bios
implementations which break if the RTC interrupts them.  They should be
easy to back-port to 2.1R.  But, *IF* they are enabled your scheduling
algorithms and such won't be very good, and obviously the statistics.

>Is there any problem with just >leaving it dead?  Does anyone know why
it dies?  Does the (large) time >spent processing printer port
interrupts mean that clock-related >interrupts are lost, resulting in
the (permanent) failure of the >secondary clock?

Possibly.  Bruce Evans would be the better person to answer this, and he
sometimes hangs out on Usenet.

> Is there a software fix for this?  Should I be looking at my hardware
> setup?

I suspect hardware given that I've not had problems going from a
slow-laptop to a fast deskopt, fask-laptop to a slow-desktop, and all of
the other permutations, but you may be able to work around the problem with
some judiciously placed spl() calls.



Nate


-- 
nate@sri.com           | Research Engineer, SRI Intl. - Montana Operations
nate@trout.mt.sri.com  | Loving life in God's country, the great state of
work #: (406) 449-7662 | Montana (all the crazies are now in jail 'cept us
home #: (406) 443-7063 | natives). - Fly fishing fanatic!