Jarle Greipsland <jarle@runit.sintef.no> writes:

> diff -u0 -r1.1 com_pcmcia.c
> --- com_pcmcia.c        1999/03/28 11:23:32     1.1
> +++ com_pcmcia.c        1999/03/29 21:35:16
> @@ -242 +242 @@
> -                       if ((cfe->iomask != 3) && (cfe->iospace[0].start != 0)) {
> +                       if ((cfe->iospace[0].start != 0)) {
> 
> then the card again get mapped at one of the I/O slots returned by the
> card, and everything works normally again.  (This is definitely not
> the appropriate fix, but it was the first mod I made where the modem
> again worked).
> 
> I don't know much about the whole PCMCIA stuff, so someone more
> knowledgeable should probably tell us what is the problem here.
> 
> o Is my modem card somehow at fault?  Does it return entries it should
>   not, or is it being more strict than what it tells the system?
>   Should it have some sort of `quirks' entry?

	The modem does have a problem, yes; it specifies the I/O range
it wants, but gives an iomask (relevant number of bits) for them as
3. The range 0x3f8 - 0x3ff is equivalent to the range 0x0 - 0x7 with
only three bits signifigant. If it really wants that range it should
give an iomask of 10. 

> o Is the PCMCIA probing and mapping mechanisms for serial ports in
>   NetBSD-current broken in some way?  Are other cards just more forgiving?

	The code which tripped you up (which I wrote) could be changed
to be more robust in the face of broken cards like yours. The
heuristic it was using is a little weird, and I have some better
ideas. I'll take a look at changing it.

	- Nathan