> on boot:
>  com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
>  com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
>  com2 at isa0 port 0x3e8-0x3ef irq 5: ns16550a, working fifo

> however:
>  isapnp0 at isa0 port 0x279: read port 0x203
>  isapnp0: <CIRRUS LOGIC PnP V24 MODEM, CIR3000, , > port 0x2e8/8 irq3 not config
ured

It is simply not recognized as PnP device. You could try

Index: com_isapnp.c
===================================================================
RCS file: /cvsroot/src/sys/dev/isapnp/com_isapnp.c,v
retrieving revision 1.6.2.2
diff -c -2 -r1.6.2.2 com_isapnp.c
*** com_isapnp.c	1998/05/08 06:50:40	1.6.2.2
--- com_isapnp.c	1998/12/20 19:08:07
***************
*** 82,85 ****
--- 82,86 ----
  	    strcmp(ipa->ipa_devlogic, "ROK0010") && /* Rockwell ? */
  	    strcmp(ipa->ipa_devlogic, "USR2070") && /* USR Sportster 56k */
+ 	    strcmp(ipa->ipa_devlogic, "CIR3000") && /* Cirrus Logic V43 */
  	    strcmp(ipa->ipa_devcompat, "PNP0500") && /* generic 8250/16450 */
  	    strcmp(ipa->ipa_devcompat, "PNP0501")) /* generic 16550A */

on 1.3.x, or

Index: isapnpdevs
===================================================================
RCS file: /cvsroot/src/sys/dev/isapnp/isapnpdevs,v
retrieving revision 1.12
diff -c -2 -r1.12 isapnpdevs
*** isapnpdevs	1998/12/02 09:42:57	1.12
--- isapnpdevs	1998/12/20 19:10:32
***************
*** 76,79 ****
--- 76,80 ----
  devlogic	com	USR2070		USR Sportster 56k
  devlogic	com	ZTIF761		Zoom ComStar 33.6
+ devlogic	com	CIR3000		Cirrus Logic V43
  devcompat	com	PNP0500		Generic 8250/16450
  devcompat	com	PNP0501		Generic 16550A

on -current.
This should work if the modem behaves well.

> And when the device is accessed, the system halts.  Suggestions for
> fixing this problem would be much appreciated.

You either got a false positive from a com port probe, which
unfortunately happens quite often with newer chipsets, or the
PnP modem responded to another address before it got reconfigured
by the PnP mechanism (which shouldn't happen, but...).
(The latter is more likely as it was recognized "ns16550a, working fifo".)
So it couldn't access the real device and the driver went into
the desert.
In any case, once the device is known to the kernel it will
hopefully "just work". You can still get false positives, so
watch the boot output and use the right one.

best regards
Matthias