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!