Well, after lots of kernel rebuilds, inserting a printf() here and there 
(and pretty much everywhere), I _think_ I've found the problem:

It seems that routine get_mapping() (in sys/arch/mac68k/mac68k/machdep.c) 
is responsible for finding the original (MacOS set-up) mapping for the 
video address.  In the case where I've got the monitor attached to the 
internal video, but still have the nubus card installed in the Mac, it 
appears to find a nubus range that meets the various requirements.  So, 
it dutifully resets the mac68k_vidphys variable that was set in routine 
bootstrap_mac68k() (in file pmap_bootstrap.c).  So routine check_video() 
(back in machdep.c) never gets called, and routine pmap_bootstrap() 
"relocates" the internal video RAM to to some strange place.  Later on, 
when ite_match() attempts to get the physical address corresponding to 
the relocated video RAM (by calling pmap_extract()) it gets a return 
value of zero, which of course doesn't match the original physical 
address (in my case, 0xfbb08000), so it doesn't attach the ite device.

Now, if only I could figure out what to do to fix this...  :)

---------- Forwarded message ----------

I was just trying to build a kernel that would support both my nubus 
video card and my Mac IIci's internal video, so it wouldn't matter where 
my monitor was attached when I boot NetBSD.  So, I put the following in 
my system configuration file, and built the kernel from scratch:

	nubus0		at mainbus0

	macvid0		at nubus0	# Video card
	intvid0		at obio0	# Internal video hardware

	# Attach grf semantics to video hardware
	grf*		at intvid0
	grf*		at macvid0

	# Attach ite semantics to the appropriate grf device
	ite0		at grf?

The resulting kernel boots into single-user mode successfully, whether 
the monitor is attached to the video card or to internal video.  But, 
when the monitor is attached to internal video, the ite0 minimal console 
doesn't get configured!  Needless to say, this plays havoc with other 
stuff, like X!  ite0 gets configured correctly when the monitor is 
attached to the nubus card.

I've tracked it down to rouine iteattach() in ite.c, where it seems that 
the call to pmap_extract() returns zero, which of course won't match the 
value for conspa.

Any ideas on why this would happen?  Has something/someone stomped on a 
critical piece of memory?