From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 24 09:38:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B852416A4B3 for ; Wed, 24 Sep 2003 09:38:51 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (B76a1.pppool.de [213.7.118.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D81D44008 for ; Wed, 24 Sep 2003 09:36:16 -0700 (PDT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:d507:76a1:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id h8OGYB402796 verified NO) for ; Wed, 24 Sep 2003 18:34:13 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id h8OGYBr02795; Wed, 24 Sep 2003 18:34:11 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 24 Sep 2003 18:34:11 +0200 (CEST) Message-Id: <200309241634.h8OGYBr02795@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200309152127.h8FLRrv71220@Mail.NOSPAM.DynDNS.dK> <200309180455.h8I4tBK58276@Mail.NOSPAM.DynDNS.dK> <3F697DBF.9CE6E9C@mindspring.com> To: FreeBSD List of Hackers Subject: Re: Machine wedges solid after one serial-port source-lineaddition... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2003 16:38:51 -0000 [Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Terry Lambert writes: > I remember wakeup() being bad. Taking any time to do anything > at all more than just queueing data and going away is probably > bad. Then that's probably why it worked fine for some hours, then failed miserably. Thanks! > If it were my project, I'd mirror the values out to a status > structure that's only written at interrupt, and read and reset > at software interrupt, and then use the soft interrupt handler > to raise the signals/send the wakeup/whatever and then resets > the flags bits to zero via a call down that synchronizes like Maybe I'll turn back to this, when I'm older and wiser. But also, serial ports are a scarcity for me, so I'm wondering what else I can use to get precise timing information, to free up the serial port for something else. I wrote earlier (from an invalid address that probably most list readers rejected as spam) that I had a problem accessing the parallel port nACK as /dev/pps for the precise timing already present in the kernel source, and simultaneously as /dev/ppi for coarse timing via polling from which I'd determine the time that the PPS signal refers to. I tried adding printf()s to various parallel-port kernel code to see if there might be an interrupt I could jump onto for each transition of the nACK status line, but I suspect my lack of success with both swings of the signal has to do with not doing it right. So I'll ask a basic question here, forgive my ignorance: Can the lines of the parallel port be used to generate interrupts that I can use, in the same way that I've been able to use the four serial port status lines, or is this right out? And another question, I see three unused joystick connectors on the three sound cards in my machine, that are less likely to be used than the so-far- unused parallel port. Would it be possible to get interrupts from the sound card's joystick connector, when interfaced with suitable hardware to the radio clock output, that I would also theoretically be able to use? Or is this also something I'd need to poll the status of the switch(es), so only coarse precision would be possible? Please excuse my basic ignorance of fundamental PC hardware principles, and I'll welcome pointers to sources of more knowledge. Thanks, Barry Bouwsma