Well, it appears that I was a victim of:

====================== sys/dev/isa/i82365_isasubr.c =======================
revision 1.21
date: 2000/05/09 17:59:39;  author: jhawk;  state: Exp;  lines: +1 -20
Back out rev 1.7 of i82365_isa.c; 0x300-0x3ff, or even 0x330-0x3ff
is not a reasonable place to allocate 12-bit pcmcia iospace.
It seems to cause conflicts on a large number of modern laptops,
necesitating hand-patching of the kernel (mostly due to
video devices in the upper range of that space).

This will presumably cause problems on the NEC Versa 6030X,
however that appears to be a vastly less common case than
the laptops that are inconvenienced by the current state.

12-bit iospace now uses 0x400-0xfff.
===========================================================================

Note that there is also the following comment in the code:
        /*
         * XXX some hardware doesn't seem to grok addresses in 0x400 range--
         * apparently missing a bit or more of address lines. (e.g.
         * CIRRUS_PD672X with Linksys EthernetCard ne2000 clone in TI
         * TravelMate 5000--not clear which is at fault)
         *
         * Add a kludge to detect 10 bit wide buses and deal with them,
         * and also a config file option to override the probe.
         */

I am running a Toshiba 2110CS Satellite notebook (486 DX2/66).  It
runs fine, but the ep0 card interrupts weren't working properly when
configured with I/O space at 0x400-0x40f.

In case it helps someone else...  Adding

	options         PCIC_ISA_ALLOC_IOBASE="0x300"   
	options         PCIC_ISA_ALLOC_IOSIZE="0x0ff"   

to my kernel config got me working again.

Is there any way to make this more robust?  Or to make sure that users
have some clue about how to change this to get it to work?  I consider
myself pretty clueful on the whole and I had to dig for a while to
figure this out (and I didn't get any messages with suggestions, so it
must not be a trivial and well-known problem)...

Should there be a rogues gallery for devices that don't work at the
higher I/O addresses so that we can point people in this direction
if the device probes and gets added with those addresses?

-allen