From owner-freebsd-hackers Mon Jul 8 21:10:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA08411 for hackers-outgoing; Mon, 8 Jul 1996 21:10:09 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA08368; Mon, 8 Jul 1996 21:09:56 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id VAA06262; Mon, 8 Jul 1996 21:09:17 -0700 (PDT) Message-ID: <31E1DB6C.167EB0E7@FreeBSD.org> Date: Mon, 08 Jul 1996 21:09:17 -0700 From: "Jordan K. Hubbard" Organization: Walnut Creek CDROM X-Mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: phk@FreeBSD.org CC: hackers@FreeBSD.org Subject: [Fwd: Parallel laplink abuse leads to death of kernel secondary timer] Content-Type: multipart/mixed; boundary="------------794BDF32446B9B3D2781E494" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------794BDF32446B9B3D2781E494 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yow, this one's pretty cool! :-) I guess we always knew that PLIP was a high-overhead proposition, but it's interesting to see that it only croaks on the Pentium. Jordan --------------794BDF32446B9B3D2781E494 Content-Type: message/news Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: reason.cdrom.com!news1.crl.com!nntp.crl.com!news.PBI.net!news.mathworks.com!news.kei.com!nntp.coast.net!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 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. --------------794BDF32446B9B3D2781E494--