steve@nuchat.UUCP (Steve Nuchia) (02/27/90)
It being spring break and all, I was hacking on my serial driver and discovered something strange... I had been having system lockups you see, and the only excuse I could think of for them was that my interupt service routine was infinite looping. And the only excuse I could figure for that was an SPL botch. I really don't think its an spl botch on my part, I think its something the system is doing for me that I don't understand. I added reentry detection to the ISR and sure enough it is being reentered, so I'm stumped. For the time being I'm just returning if the "active" flag is set. The driver serves more than one interupt line, and the ISR is called from the upper half, from a timeout, and on hardware interupts. It services all attached devices on each interupt, since the devices have internal queues (NS16550As). The upper-half call is inside an spl7, the timeout calls a stub that calls the ISR and reschedules itself, inside an spl7. Anybody have any clues? If somebody would like to examine the source I'd be grateful, and happy to mail a copy. The good news is that I squoze another 20% or so out of the overhead, it has now demonstrated 3500 cps aggregate instantaneous throughput, 2500 was my best previous, and cpu utilization at high baud rates is way down -- I had 55-65% idle during the speed run. The system is a 16 MHz non-cache 386 with Bell Tech sysVr3.0 (waiting for r4 before I spring for an upgrade). The devices are an internal modem with an intel 8250 chip and a digiboard 8-port dumb card with NS16550A's on it, two hooked to telebit TB+s and 6 dangling. I also hacked in a nap ioctl and an ioctl to return the character count in the raw queue; needed them to get "nbstime" working. I now have my rc script call the NIST time standard when I boot. What a trip. My mods to nbstime also available. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "You have no scars on your face, and you cannot handle pressure." - Billy Joel