(I apoligise in advance if this gets in twice...)

I'm trying to get netBSD (i386) to talk to my PCI hardware modem....

(it's a CONEXANT HCP P85 DATA/FAX masquerading as a Diamond Multimedia
Supra Express 56i PRO.  PCI ID 14f1/1033, subvendor 1092/ac8)

I've added the relevant data to puc_data.c - and it is recognised as an
ns16550 modem with working fifos.

However the system reboot locked running the startup scripts.  Diagnostics
showed that the 'com_intr' routine was been called and reading 'iir' = 0x20.
This isn't a valid number for the 'standard' uart datasheet I have.

Hacked com_intr to ignore this value.
(actually it is probably worth exiting the loop after a few 100 interations
anyway, because something is up...  kill MIE in MCR as wel...)
Interrupt doesn't loop - so either edge sensitive somewhere or the h/w
has removed its IRQ...

At this point I tried to install a new driver for windows 98 (found on the
conexant web site), took all afternoon to get a working modem.

Card now in a different slot, on a different IRQ, probably now shared with
my ethernet card...

Now I don't get any ISRs coming in at all....

However I've found a larger problem with the tty system as a whole.
During close() the kernel waits for terminal output to drain.
This is (effectively) indefinite and uninteruptable.
With a stuffed tty driver the close blocks for ever - even kill -9 just
leaves a zombie.

It seems to me that there should be a timeout on this flush....

I also noticed that the code looks wrong anyway.
tywflush currently reads:

        if ((error = ttywait(tp)) == 0)
                ttyflush(tp, FREAD);
        return (error);

Now, this is only ever used during 'close()' and non of the callers expect
(or maybe care) whether it fails.  Since leaving data in the tty buffers
will have odd effects.  It would be better if it read:

        error = ttywait( tp );
        ttyflush( tp, FREAD | FWRITE );
        return error;

That way no data is ever left lurking in the (software) fifos.

Adding a timeout to the ttywait() call is easy - 10*hz should be more than
enough to allow output that will drain to drain...

That just leaves me with the modem questions IRQ/ISR problems....

    David