Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!mmcg From: mmcg@cs.monash.edu.au (Mike Mc Gaughey) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Parallel laplink abuse leads to death of kernel secondary timer Date: 7 Jul 1996 01:40:41 GMT Organization: Monash University Lines: 42 Message-ID: <4rn4ip$kcr@harbinger.cc.monash.edu.au> NNTP-Posting-Host: molly.cs.monash.edu.au X-NNTP-Posting-User: mmcg Summary: When I use lpt0 (for tcp/ip) too much, kernel timer dies Keywords: printer port laplink cable timer Hi, all, I'm running FreeBSD 2.1.0-R on two machines, connected by a parallel laplink cable. The first is a 486/33, with a printer port on a multi I/O card. The second is a P90, printer port on motherboard. The link is set up as a network interface between the machines; ftp, rlogin, etc, work pretty well over it (albiet at only 60K/sec). When doing a large FTP, `top' reports that 60-70% of CPU time (on each machine) is spent processing interrupts (whether or not the printer port on the P90 is set up to generate interrupts :). Here's the interesting bit: if an FTP lasts for more than about a minute, `systat' (when displaying vmstat) complains that `the kernel secondary timer has died' - and it stays dead, even after the link becomes quiescent. As far as I can tell from the kernel sources, this timer runs at some multiple of the primary (real-time) timer, and is used mainly for profiling; after it dies, various statistics aren't updated (e.g. the CPU times and percentages on `top' become static). This has only ever happened on the pentium (and it doesn't seem to matter how the printer port is set up; there are several different options in the bios, for generating interrupts based on various signals - not that I'm certain they have any effect on the hardware :). A reboot fixes it. What I want to know is: is this a major problem? 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)? 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? Is there a software fix for this? Should I be looking at my hardware setup? Cheers, Mike. -- Mike McGaughey AARNET: mmcg@molly.cs.monash.edu.au "Thousands at his bidding speed, And post o'er land and ocean without rest" - Milton.