Date: Mon, 08 Jul 1996 21:09:17 -0700 From: "Jordan K. Hubbard" <jkh@FreeBSD.org> To: phk@FreeBSD.org Cc: hackers@FreeBSD.org Subject: [Fwd: Parallel laplink abuse leads to death of kernel secondary timer] Message-ID: <31E1DB6C.167EB0E7@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31E1DB6C.167EB0E7>