Hi Wayne,

First of all, thank you for your suggestions!! Will try that path and let you
know what I find.

To correctly answer your question about the hardware bug, it hass got
something to do with the way the serial port is hooked up to the cpu. For
some reason, if there is an interrupt pending from the serial port and you
access the serial port without clearing the interrupt, the serial port locks
up. It is unfortunate, but that is how it is. As far as the actual cause of
the problem, I don't know because I am really poor in understanding the
signals etc.

Thank you again and I will inform you what I find out.

Bharani.

Wayne Knowles wrote:

>
>
> That is a strange hardware bug.  Care to share more details??
> Do we have the wrong edge or level triggering the interrupt??
>
> You might want to try using soft interrupts instead of the sleep/wakeup
> mechanism - it has lower overheads and a faster service time.
>
> In the interrupt handler replace the wakeup call with setsoftserial
> (or softintr_schedule if the platform supports generic software interrupts
> such as the alpha) - perhaps set a flag in the softc structure to say a
> transmit buffer interrupt is pending.
>
> In the soft interrupt handler you can test for the transmit buffer
> condition and call write_bytes.  If you are worried about transmit
> interrupts re-occuring you can feed it from a loop:
>
> in comintr:
>         ...
>         sc->sc_tbe_pending = 1;
>         setsoftserial();  /* see dev/ic/com.c for this part */
>         ...
>
> in comsoft:
>         ...
>         while (sc->sc_tbe_pending) {
>                 sc->sc_tbe_pending = 0;
>                 write_bytes();
>         }
>         ...
>
> This can be done using a flag or semaphore to signal the state between
> the two parts of the code, but you need an atomic update at splhigh() or
> the highest processor level that updates the flag which may be splserial()
> in order to avoid race conditions/lost inetrrupts....
>
> Personally I would have a crack at the softintr solution first.
>
> Wayne.